From owner-freebsd-arch@FreeBSD.ORG Sun Oct 31 01:00:17 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5749716A4CE for ; Sun, 31 Oct 2004 01:00:17 +0000 (GMT) Received: from web14825.mail.yahoo.com (web14825.mail.yahoo.com [216.136.225.196]) by mx1.FreeBSD.org (Postfix) with SMTP id 1CA0A43D2F for ; Sun, 31 Oct 2004 01:00:15 +0000 (GMT) (envelope-from rosti_bsd@yahoo.com) Message-ID: <20041031010015.34408.qmail@web14825.mail.yahoo.com> Received: from [212.143.154.227] by web14825.mail.yahoo.com via HTTP; Sat, 30 Oct 2004 18:00:15 PDT Date: Sat, 30 Oct 2004 18:00:15 -0700 (PDT) From: Rostislav Krasny To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: PPPoE ADSL connection support during FTP installation with floppies X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2004 01:00:17 -0000 Hi. As you know FreeBSD supports many ways of installation. It can be installed from a local storage medium, such as CD or hard disk. It can also be installed from a network. For example it can be installed from remote FTP or NFS server. But network installation needs a Data Link layer support, such as Ethernet, SLIP or PPP. FreeBSD supports the PPP protocol for analog modems, connected to a serial communication port. But today such analog modems are little used in general and practically are unusable for FreeBSD installation. Instead of slow analog modems people are moving to xDSL and DOCSIS (cable) connection with their Internet providers. They are still using modems, but high-speed digital modems. Most of the ADSL modems can be accessed by the PPPoE protocol. FreeBSD 4.x have an unofficial method of installation from FTP server over a PPPoE connection. I used this method many times and whereas it is unofficial and tricky, I found it handy and useful. I didn't download ISO images but only the floppies images, and during the FTP installation I've download only actually installed parts of the system and of the packages collection. Unfortunately FreeBSD 5.x (at least the upcoming 5.3) have no way of installation over the PPPoE connection. Is it possibly to recover the FTP installation method over PPPoE and make it official and not so tricky in the sysinstall(8) at the future 5.4 or 6.0 versions of FreeBSD? __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-freebsd-arch@FreeBSD.ORG Tue Nov 2 09:23:33 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9621716A4CE for ; Tue, 2 Nov 2004 09:23:33 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B85643D1F for ; Tue, 2 Nov 2004 09:23:32 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) iA29NUU539368 for ; Tue, 2 Nov 2004 10:23:30 +0100 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) iA29NTI344884 for ; Tue, 2 Nov 2004 10:23:29 +0100 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id iA29Noe11132 for ; Tue, 2 Nov 2004 10:23:50 +0100 (MET) Date: Tue, 2 Nov 2004 10:23:29 +0100 (CET) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: arch@freebsd.org Message-ID: <20041102100958.S70286@beagle.kn.op.dlr.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Remote stuff in make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2004 09:23:33 -0000 Hi all, I want to remove the remote stuff from our make to make maintenance easier. Remote make has been disfunctional from the original import on - the necessary files have never been imported. The base system doesn't use that feature (and has no need to), ports have their own remote built stuff AFIK. If actually someone would need this - there is the pmake port that really contains this stuff. If anybody has a good reason why we need to keep this (and the associated patches to make it work + the willingness to support it in the future) - please speak up now. Attached is a diff that just removes the #defines and #ifdefs. The MD5 of the produced make is the same as before. harti Index: job.c =================================================================== RCS file: /local/cvs/freebsd/src/usr.bin/make/job.c,v retrieving revision 1.52 diff -u -r1.52 job.c --- job.c 23 Oct 2004 21:36:55 -0000 1.52 +++ job.c 2 Nov 2004 09:19:51 -0000 @@ -123,12 +123,8 @@ #include "dir.h" #include "job.h" #include "pathnames.h" -#ifdef REMOTE -#include "rmt.h" -# define STATIC -#else -# define STATIC static -#endif + +#define STATIC static /* * error handling variables @@ -239,14 +235,12 @@ * running jobs equals the maximum allowed or * (2) a job can only be run locally, but * nLocal equals maxLocal */ -#ifndef RMT_WILL_WATCH #ifdef USE_KQUEUE static int kqfd; /* File descriptor obtained by kqueue() */ #else static fd_set outputs; /* Set of descriptors of pipes connected to * the output channels of children */ #endif -#endif STATIC GNode *lastNode; /* The node for which output was most recently * produced. */ @@ -254,15 +248,9 @@ * job when it's not the most-recent job heard * from */ -#ifdef REMOTE -# define TARG_FMT "--- %s at %s ---\n" /* Default format */ -# define MESSAGE(fp, gn) \ - (void) fprintf(fp, targFmt, gn->name, gn->rem.hname); -#else -# define TARG_FMT "--- %s ---\n" /* Default format */ -# define MESSAGE(fp, gn) \ +#define TARG_FMT "--- %s ---\n" /* Default format */ +#define MESSAGE(fp, gn) \ (void) fprintf(fp, targFmt, gn->name); -#endif /* * When JobStart attempts to run a job remotely but can't, and isn't allowed @@ -311,15 +299,8 @@ static int JobPrintCommand(void *, void *); static int JobSaveCommand(void *, void *); static void JobClose(Job *); -#ifdef REMOTE -static int JobCmpRmtID(Job *, int); -# ifdef RMT_WILL_WATCH -static void JobLocalInput(int, Job *); -# endif -#else static void JobFinish(Job *, int *); static void JobExec(Job *, char **); -#endif static void JobMakeArgv(Job *, char **); static void JobRestart(Job *); static int JobStart(GNode *, int, Job *); @@ -348,20 +329,13 @@ { Job *job = (Job *) jobp; int signo = *(int *) signop; -#ifdef RMT_WANTS_SIGNALS - if (job->flags & JOB_REMOTE) { - (void) Rmt_Signal(job, signo); - } else { - KILL(job->pid, signo); - } -#else + /* * Assume that sending the signal to job->pid will signal any remote * job as well. */ DEBUGF(JOB, ("JobCondPassSig passing signal %d to child %d.\n", signo, job->pid)); KILL(job->pid, signo); -#endif return 0; } @@ -454,27 +428,6 @@ return *(int *) pid - ((Job *) job)->pid; } -#ifdef REMOTE -/*- - *----------------------------------------------------------------------- - * JobCmpRmtID -- - * Compare the rmtID of the job with the given rmtID and return 0 if they - * are equal. - * - * Results: - * 0 if the rmtID's match - * - * Side Effects: - * None. - *----------------------------------------------------------------------- - */ -static int -JobCmpRmtID(void *job, void *rmtID) -{ - return(*(int *) rmtID - *(int *) job->rmtID); -} -#endif - /*- *----------------------------------------------------------------------- * JobPrintCommand -- @@ -702,9 +655,7 @@ JobClose(Job *job) { if (usePipes) { -#ifdef RMT_WILL_WATCH - Rmt_Ignore(job->inPipe); -#elif !defined(USE_KQUEUE) +#if !defined(USE_KQUEUE) FD_CLR(job->inPipe, &outputs); #endif if (job->outPipe != job->inPipe) { @@ -759,18 +710,11 @@ * cases, finish out the job's output before printing the exit * status... */ -#ifdef REMOTE - KILL(job->pid, SIGCONT); -#endif JobClose(job); if (job->cmdFILE != NULL && job->cmdFILE != stdout) { (void) fclose(job->cmdFILE); } done = TRUE; -#ifdef REMOTE - if (job->flags & JOB_REMOTE) - Rmt_Done(job->rmtID, job->node); -#endif } else if (WIFEXITED(*status)) { /* * Deal with ignored errors in -B mode. We need to print a message @@ -787,10 +731,6 @@ * stuff? */ JobClose(job); -#ifdef REMOTE - if (job->flags & JOB_REMOTE) - Rmt_Done(job->rmtID, job->node); -#endif /* REMOTE */ } else { /* * No need to close things down or anything. @@ -851,10 +791,6 @@ } job->flags |= JOB_RESUME; (void)Lst_AtEnd(stoppedJobs, (void *)job); -#ifdef REMOTE - if (job->flags & JOB_REMIGRATE) - JobRestart(job); -#endif (void) fflush(out); return; } else if (WTERMSIG(*status) == SIGCONT) { @@ -1120,27 +1056,6 @@ } return TRUE; } -#ifdef RMT_WILL_WATCH -/*- - *----------------------------------------------------------------------- - * JobLocalInput -- - * Handle a pipe becoming readable. Callback function for Rmt_Watch - * - * Results: - * None - * - * Side Effects: - * JobDoOutput is called. - * - *----------------------------------------------------------------------- - */ -/*ARGSUSED*/ -static void -JobLocalInput(int stream, Job *job) -{ - JobDoOutput(job, FALSE); -} -#endif /* RMT_WILL_WATCH */ /*- *----------------------------------------------------------------------- @@ -1186,12 +1101,6 @@ lastNode = job->node; } -#ifdef RMT_NO_EXEC - if (job->flags & JOB_REMOTE) { - goto jobExecFinish; - } -#endif /* RMT_NO_EXEC */ - if ((cpid = vfork()) == -1) { Punt("Cannot fork"); } else if (cpid == 0) { @@ -1245,20 +1154,12 @@ # endif #endif /* USE_PGRP */ -#ifdef REMOTE - if (job->flags & JOB_REMOTE) { - Rmt_Exec(shellPath, argv, FALSE); - } else -#endif /* REMOTE */ - (void) execv(shellPath, argv); + (void) execv(shellPath, argv); (void) write(STDERR_FILENO, "Could not execute shell\n", sizeof("Could not execute shell")); _exit(1); } else { -#ifdef REMOTE - long omask = sigblock(sigmask(SIGCHLD)); -#endif job->pid = cpid; if (usePipes && (job->flags & JOB_FIRST) ) { @@ -1272,9 +1173,7 @@ #endif job->curPos = 0; -#ifdef RMT_WILL_WATCH - Rmt_Watch(job->inPipe, JobLocalInput, job); -#elif defined(USE_KQUEUE) +#if defined(USE_KQUEUE) EV_SET(&kev[0], job->inPipe, EVFILT_READ, EV_ADD, 0, 0, job); EV_SET(&kev[1], job->pid, EVFILT_PROC, EV_ADD | EV_ONESHOT, NOTE_EXIT, 0, NULL); @@ -1285,15 +1184,11 @@ } #else FD_SET(job->inPipe, &outputs); -#endif /* RMT_WILL_WATCH */ +#endif /* USE_KQUEUE */ } if (job->flags & JOB_REMOTE) { -#ifndef REMOTE job->rmtID = 0; -#else - job->rmtID = Rmt_LastID(job->pid); -#endif /* REMOTE */ } else { nLocal += 1; /* @@ -1304,14 +1199,8 @@ job->cmdFILE = NULL; } } -#ifdef REMOTE - (void) sigsetmask(omask); -#endif } -#ifdef RMT_NO_EXEC -jobExecFinish: -#endif /* * Now the job is actually running, add it to the table. */ @@ -1391,80 +1280,41 @@ static void JobRestart(Job *job) { -#ifdef REMOTE - int host; -#endif if (job->flags & JOB_REMIGRATE) { - if ( -#ifdef REMOTE - verboseRemigrates || -#endif - DEBUG(JOB)) { + if (DEBUG(JOB)) { (void) fprintf(stdout, "*** remigrating %x(%s)\n", job->pid, job->node->name); (void) fflush(stdout); } -#ifdef REMOTE - if (!Rmt_ReExport(job->pid, job->node, &host)) { - if (verboseRemigrates || DEBUG(JOB)) { - (void) fprintf(stdout, "*** couldn't migrate...\n"); + if (nLocal != maxLocal) { + /* + * Job cannot be remigrated, but there's room on the local + * machine, so resume the job and note that another + * local job has started. + */ + if (DEBUG(JOB)) { + (void) fprintf(stdout, "*** resuming on local machine\n"); (void) fflush(stdout); } -#endif - if (nLocal != maxLocal) { - /* - * Job cannot be remigrated, but there's room on the local - * machine, so resume the job and note that another - * local job has started. - */ - if ( -#ifdef REMOTE - verboseRemigrates || -#endif - DEBUG(JOB)) { - (void) fprintf(stdout, "*** resuming on local machine\n"); - (void) fflush(stdout); - } - KILL(job->pid, SIGCONT); - nLocal +=1; -#ifdef REMOTE - job->flags &= ~(JOB_REMIGRATE|JOB_RESUME|JOB_REMOTE); - job->flags |= JOB_CONTINUING; -#else - job->flags &= ~(JOB_REMIGRATE|JOB_RESUME); -#endif - } else { - /* - * Job cannot be restarted. Mark the table as full and - * place the job back on the list of stopped jobs. - */ - if ( -#ifdef REMOTE - verboseRemigrates || -#endif - DEBUG(JOB)) { - (void) fprintf(stdout, "*** holding\n"); - (void) fflush(stdout); - } - (void)Lst_AtFront(stoppedJobs, (void *)job); - jobFull = TRUE; - DEBUGF(JOB, ("Job queue is full.\n")); - return; - } -#ifdef REMOTE + KILL(job->pid, SIGCONT); + nLocal +=1; + job->flags &= ~(JOB_REMIGRATE|JOB_RESUME); } else { /* - * Clear out the remigrate and resume flags. Set the continuing - * flag so we know later on that the process isn't exiting just - * because of a signal. + * Job cannot be restarted. Mark the table as full and + * place the job back on the list of stopped jobs. */ - job->flags &= ~(JOB_REMIGRATE|JOB_RESUME); - job->flags |= JOB_CONTINUING; - job->rmtID = host; + if (DEBUG(JOB)) { + (void) fprintf(stdout, "*** holding\n"); + (void) fflush(stdout); + } + (void)Lst_AtFront(stoppedJobs, (void *)job); + jobFull = TRUE; + DEBUGF(JOB, ("Job queue is full.\n")); + return; } -#endif (void)Lst_AtEnd(jobs, (void *)job); nJobs += 1; @@ -1486,43 +1336,23 @@ JobMakeArgv(job, argv); DEBUGF(JOB, ("Restarting %s...", job->node->name)); -#ifdef REMOTE - if ((job->node->type&OP_NOEXPORT) || - (nLocal < maxLocal && runLocalFirst) -# ifdef RMT_NO_EXEC - || !Rmt_Export(shellPath, argv, job) -# else - || !Rmt_Begin(shellPath, argv, job->node) -# endif -#endif - { - if (((nLocal >= maxLocal) && !(job->flags & JOB_SPECIAL))) { - /* - * Can't be exported and not allowed to run locally -- put it - * back on the hold queue and mark the table full - */ - DEBUGF(JOB, ("holding\n")); - (void)Lst_AtFront(stoppedJobs, (void *)job); - jobFull = TRUE; - DEBUGF(JOB, ("Job queue is full.\n")); - return; - } else { - /* - * Job may be run locally. - */ - DEBUGF(JOB, ("running locally\n")); - job->flags &= ~JOB_REMOTE; - } - } -#ifdef REMOTE - else { + if (((nLocal >= maxLocal) && !(job->flags & JOB_SPECIAL))) { + /* + * Can't be exported and not allowed to run locally -- put it + * back on the hold queue and mark the table full + */ + DEBUGF(JOB, ("holding\n")); + (void)Lst_AtFront(stoppedJobs, (void *)job); + jobFull = TRUE; + DEBUGF(JOB, ("Job queue is full.\n")); + return; + } else { /* - * Can be exported. Hooray! + * Job may be run locally. */ - DEBUGF(JOB, ("exporting\n")); - job->flags |= JOB_REMOTE; + DEBUGF(JOB, ("running locally\n")); + job->flags &= ~JOB_REMOTE; } -#endif JobExec(job, argv); } else { /* @@ -1532,14 +1362,8 @@ DEBUGF(JOB, ("Resuming %s...", job->node->name)); if (((job->flags & JOB_REMOTE) || (nLocal < maxLocal) || -#ifdef REMOTE - (((job->flags & JOB_SPECIAL) && - (job->node->type & OP_NOEXPORT)) && - (maxLocal == 0))) && -#else ((job->flags & JOB_SPECIAL) && (maxLocal == 0))) && -#endif (nJobs != maxJobs)) { /* @@ -1552,12 +1376,7 @@ Boolean error; int status; -#ifdef RMT_WANTS_SIGNALS - if (job->flags & JOB_REMOTE) { - error = !Rmt_Signal(job, SIGCONT); - } else -#endif /* RMT_WANTS_SIGNALS */ - error = (KILL(job->pid, SIGCONT) != 0); + error = (KILL(job->pid, SIGCONT) != 0); if (!error) { /* @@ -1839,27 +1658,11 @@ } } -#ifdef REMOTE - if (!(gn->type & OP_NOEXPORT) && !(runLocalFirst && nLocal < maxLocal)) { -#ifdef RMT_NO_EXEC - local = !Rmt_Export(shellPath, argv, job); -#else - local = !Rmt_Begin(shellPath, argv, job->node); -#endif /* RMT_NO_EXEC */ - if (!local) { - job->flags |= JOB_REMOTE; - } - } else -#endif - local = TRUE; + local = TRUE; if (local && (((nLocal >= maxLocal) && !(job->flags & JOB_SPECIAL) && -#ifdef REMOTE - (!(gn->type & OP_NOEXPORT) || (maxLocal != 0)) -#else (maxLocal != 0) -#endif ))) { /* @@ -2192,14 +1995,7 @@ nJobs -= 1; DEBUGF(JOB, ("Job queue is no longer full.\n")); jobFull = FALSE; -#ifdef REMOTE - if (!(job->flags & JOB_REMOTE)) { - DEBUGF(JOB, ("Job queue has one fewer local process.\n")); - nLocal -= 1; - } -#else nLocal -= 1; -#endif } JobFinish(job, &status); @@ -2236,34 +2032,9 @@ LstNode ln; Job *job; #endif -#ifdef RMT_WILL_WATCH - int pnJobs; /* Previous nJobs */ -#endif (void) fflush(stdout); -#ifdef RMT_WILL_WATCH - pnJobs = nJobs; - /* - * It is possible for us to be called with nJobs equal to 0. This happens - * if all the jobs finish and a job that is stopped cannot be run - * locally (eg if maxLocal is 0) and cannot be exported. The job will - * be placed back on the stoppedJobs queue, Job_Empty() will return false, - * Make_Run will call us again when there's nothing for which to wait. - * nJobs never changes, so we loop forever. Hence the check. It could - * be argued that we should sleep for a bit so as not to swamp the - * exportation system with requests. Perhaps we should. - * - * NOTE: IT IS THE RESPONSIBILITY OF Rmt_Wait TO CALL Job_CatchChildren - * IN A TIMELY FASHION TO CATCH ANY LOCALLY RUNNING JOBS THAT EXIT. - * It may use the variable nLocal to determine if it needs to call - * Job_CatchChildren (if nLocal is 0, there's nothing for which to - * wait...) - */ - while (nJobs != 0 && pnJobs == nJobs) { - Rmt_Wait(); - } -#else if (usePipes) { #ifdef USE_KQUEUE if ((nfds = kevent(kqfd, NULL, 0, kev, KEV_SIZE, NULL)) == -1) { @@ -2309,7 +2080,6 @@ } #endif /* !USE_KQUEUE */ } -#endif /* RMT_WILL_WATCH */ } /*- @@ -2379,11 +2149,7 @@ lastNode = NULL; - if (maxJobs == 1 || beVerbose == 0 -#ifdef REMOTE - || noMessages -#endif - ) { + if (maxJobs == 1 || beVerbose == 0) { /* * If only one job can run at a time, there's no need for a banner, * no is there? @@ -2423,7 +2189,7 @@ * we're giving each job its own process group (since then it won't get * signals from the terminal driver as we own the terminal) */ -#if defined(RMT_WANTS_SIGNALS) || defined(USE_PGRP) +#if defined(USE_PGRP) if (signal(SIGTSTP, SIG_IGN) != SIG_IGN) { (void) signal(SIGTSTP, JobPassSig); } @@ -2450,9 +2216,7 @@ JobStart(begin, JOB_SPECIAL, (Job *)0); while (nJobs) { Job_CatchOutput(); -#ifndef RMT_WILL_WATCH Job_CatchChildren(!usePipes); -#endif /* RMT_WILL_WATCH */ } } postCommands = Targ_FindNode(".END", TARG_CREATE); @@ -2757,80 +2521,13 @@ Error("*** %s removed", file); } } -#ifdef RMT_WANTS_SIGNALS - if (job->flags & JOB_REMOTE) { - /* - * If job is remote, let the Rmt module do the killing. - */ - if (!Rmt_Signal(job, signo)) { - /* - * If couldn't kill the thing, finish it out now with an - * error code, since no exit report will come in likely. - */ - int status; - - status.w_status = 0; - status.w_retcode = 1; - JobFinish(job, &status); - } - } else if (job->pid) { - KILL(job->pid, signo); - } -#else if (job->pid) { DEBUGF(JOB, ("JobInterrupt passing signal to child %d.\n", job->pid)); KILL(job->pid, signo); } -#endif /* RMT_WANTS_SIGNALS */ } -#ifdef REMOTE - (void)Lst_Open(stoppedJobs); - while ((ln = Lst_Next(stoppedJobs)) != NULL) { - job = (Job *) Lst_Datum(ln); - - if (job->flags & JOB_RESTART) { - DEBUGF(JOB, "JobInterrupt skipping job on stopped queue" - "-- it was waiting to be restarted.\n"); - continue; - } - if (!Targ_Precious(job->node)) { - char *file = (job->node->path == NULL ? - job->node->name : - job->node->path); - if (eunlink(file) == 0) { - Error("*** %s removed", file); - } - } - /* - * Resume the thing so it will take the signal. - */ - DEBUGF(JOB, ("JobInterrupt passing CONT to stopped child %d.\n", job->pid)); - KILL(job->pid, SIGCONT); -#ifdef RMT_WANTS_SIGNALS - if (job->flags & JOB_REMOTE) { - /* - * If job is remote, let the Rmt module do the killing. - */ - if (!Rmt_Signal(job, SIGINT)) { - /* - * If couldn't kill the thing, finish it out now with an - * error code, since no exit report will come in likely. - */ - int status; - status.w_status = 0; - status.w_retcode = 1; - JobFinish(job, &status); - } - } else if (job->pid) { - DEBUGF(JOB, "JobInterrupt passing interrupt to stopped child %d.\n", - job->pid); - KILL(job->pid, SIGINT); - } -#endif /* RMT_WANTS_SIGNALS */ - } -#endif Lst_Close(stoppedJobs); if (runINTERRUPT && !touchFlag) { @@ -2841,9 +2538,7 @@ JobStart(interrupt, JOB_IGNDOTS, (Job *)0); while (nJobs) { Job_CatchOutput(); -#ifndef RMT_WILL_WATCH Job_CatchChildren(!usePipes); -#endif /* RMT_WILL_WATCH */ } } } @@ -2870,9 +2565,7 @@ while (nJobs) { Job_CatchOutput(); -#ifndef RMT_WILL_WATCH Job_CatchChildren(!usePipes); -#endif /* RMT_WILL_WATCH */ } } } @@ -2899,9 +2592,7 @@ aborting = ABORT_WAIT; while (nJobs != 0) { Job_CatchOutput(); -#ifndef RMT_WILL_WATCH Job_CatchChildren(!usePipes); -#endif /* RMT_WILL_WATCH */ } aborting = 0; } @@ -2939,18 +2630,8 @@ * kill the child process with increasingly drastic signals to make * darn sure it's dead. */ -#ifdef RMT_WANTS_SIGNALS - if (job->flags & JOB_REMOTE) { - Rmt_Signal(job, SIGINT); - Rmt_Signal(job, SIGKILL); - } else { - KILL(job->pid, SIGINT); - KILL(job->pid, SIGKILL); - } -#else KILL(job->pid, SIGINT); KILL(job->pid, SIGKILL); -#endif /* RMT_WANTS_SIGNALS */ } } @@ -2961,51 +2642,6 @@ continue; } -#ifdef REMOTE -/*- - *----------------------------------------------------------------------- - * JobFlagForMigration -- - * Handle the eviction of a child. Called from RmtStatusChange. - * Flags the child as remigratable and then suspends it. Takes - * the ID of the host we used, for matching children. - * - * Results: - * none. - * - * Side Effects: - * The job descriptor is flagged for remigration. - * - *----------------------------------------------------------------------- - */ -void -JobFlagForMigration(int hostID) -{ - Job *job; /* job descriptor for dead child */ - LstNode jnode; /* list element for finding job */ - - DEBUGF(JOB, ("JobFlagForMigration(%d) called.\n", hostID)); - jnode = Lst_Find(jobs, (void *)hostID, JobCmpRmtID); - - if (jnode == NULL) { - jnode = Lst_Find(stoppedJobs, (void *)hostID, JobCmpRmtID); - if (jnode == NULL) { - if (DEBUG(JOB)) { - Error("Evicting host(%d) not in table", hostID); - } - return; - } - } - job = (Job *) Lst_Datum(jnode); - - DEBUGF(JOB, ("JobFlagForMigration(%d) found job '%s'.\n", hostID, job->node->name)); - - KILL(job->pid, SIGSTOP); - - job->flags |= JOB_REMIGRATE; -} - -#endif - /*- *----------------------------------------------------------------------- * JobRestartJobs -- Index: job.h =================================================================== RCS file: /local/cvs/freebsd/src/usr.bin/make/job.h,v retrieving revision 1.22 diff -u -r1.22 job.h --- job.h 23 Oct 2004 21:34:41 -0000 1.22 +++ job.h 2 Nov 2004 09:20:39 -0000 @@ -207,28 +207,6 @@ extern char *shellPath; extern char *shellName; - -/* - * If REMOTE is defined then these things need exposed, otherwise they are - * static to job.c! - */ -#ifdef REMOTE -extern char *targFmt; /* Format string for banner that separates - * output from multiple jobs. Contains a - * single %s where the name of the node being - * made should be put. */ -extern GNode *lastNode; /* Last node for which a banner was printed. - * If Rmt module finds it necessary to print - * a banner, it should set this to the node - * for which the banner was printed */ -extern int nJobs; /* Number of jobs running (local and remote) */ -extern int nLocal; /* Number of jobs running locally */ -extern Lst jobs; /* List of active job descriptors */ -extern Lst stoppedJobs; /* List of jobs that are stopped or didn't - * quite get started */ -extern Boolean jobFull; /* Non-zero if no more jobs should/will start*/ -#endif - extern int maxJobs; /* Number of jobs that may run */ Index: main.c =================================================================== RCS file: /local/cvs/freebsd/src/usr.bin/make/main.c,v retrieving revision 1.92 diff -u -r1.92 main.c --- main.c 23 Oct 2004 21:34:41 -0000 1.92 +++ main.c 2 Nov 2004 09:19:51 -0000 @@ -168,11 +168,7 @@ int c; optind = 1; /* since we're called more than once */ -#ifdef REMOTE -# define OPTFLAGS "BC:D:E:I:L:PSV:Xd:ef:ij:km:nqrstv" -#else -# define OPTFLAGS "BC:D:E:I:PSV:Xd:ef:ij:km:nqrstv" -#endif +#define OPTFLAGS "BC:D:E:I:PSV:Xd:ef:ij:km:nqrstv" rearg: while((c = getopt(argc, argv, OPTFLAGS)) != -1) { switch(c) { case 'C': @@ -198,20 +194,6 @@ compatMake = TRUE; MFLAGS_append("-B", NULL); break; -#ifdef REMOTE - case 'L': { - char *endptr; - - maxLocal = strtol(optarg, &endptr, 10); - if (maxLocal < 0 || *endptr != '\0') { - warnx("illegal number, -L argument -- %s", - optarg); - usage(); - } - MFLAGS_append("-L", optarg); - break; - } -#endif case 'P': usePipes = FALSE; MFLAGS_append("-P", NULL); @@ -302,9 +284,7 @@ optarg); usage(); } -#ifndef REMOTE maxLocal = maxJobs; -#endif MFLAGS_append("-j", optarg); break; } @@ -599,11 +579,7 @@ jobsRunning = FALSE; maxLocal = DEFMAXLOCAL; /* Set default local max concurrency */ -#ifdef REMOTE - maxJobs = DEFMAXJOBS; /* Set default max concurrency */ -#else maxJobs = maxLocal; -#endif forceJobs = FALSE; /* No -j flag */ compatMake = FALSE; /* No compat mode */ From owner-freebsd-arch@FreeBSD.ORG Tue Nov 2 09:49:12 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F88F16A4CE; Tue, 2 Nov 2004 09:49:12 +0000 (GMT) Received: from gidgate.gid.co.uk (gid.co.uk [194.32.164.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FB3943D3F; Tue, 2 Nov 2004 09:49:10 +0000 (GMT) (envelope-from rb@gid.co.uk) Received: (from rb@localhost) by gidgate.gid.co.uk (8.11.7/8.11.6) id iA29n6B92671; Tue, 2 Nov 2004 09:49:06 GMT (envelope-from rb) Message-Id: <6.1.2.0.2.20041102094540.04a658e8@gid.co.uk> X-Sender: rbmail@gid.co.uk (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 02 Nov 2004 09:49:01 +0000 To: Harti Brandt From: Bob Bishop In-Reply-To: <20041102100958.S70286@beagle.kn.op.dlr.de> References: <20041102100958.S70286@beagle.kn.op.dlr.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: arch@freebsd.org Subject: Re: Remote stuff in make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2004 09:49:12 -0000 Hi, At 09:23 02/11/2004, Harti Brandt wrote: >Hi all, > >I want to remove the remote stuff from our make to make maintenance >easier. Remote make has been disfunctional from the original import on - >the necessary files have never been imported. The base system doesn't use >that feature (and has no need to), ports have their own remote built stuff >AFIK. If actually someone would need this - there is the pmake port that >really contains this stuff. > >If anybody has a good reason why we need to keep this (and the associated >patches to make it work + the willingness to support it in the future) - >please speak up now. For my money, kill it and don't think twice. However, there's a lot of related nonsense like .NOTPARALLEL and silent manipulation of the -B option which ought to be tidied up too. >Attached is a diff that just removes the #defines and #ifdefs. The MD5 of >the produced make is the same as before. > >harti > > >Index: job.c >=================================================================== >RCS file: /local/cvs/freebsd/src/usr.bin/make/job.c,v >retrieving revision 1.52 >diff -u -r1.52 job.c >--- job.c 23 Oct 2004 21:36:55 -0000 1.52 >+++ job.c 2 Nov 2004 09:19:51 -0000 >@@ -123,12 +123,8 @@ > #include "dir.h" > #include "job.h" > #include "pathnames.h" >-#ifdef REMOTE >-#include "rmt.h" >-# define STATIC >-#else >-# define STATIC static >-#endif >+ >+#define STATIC static > > /* > * error handling variables >@@ -239,14 +235,12 @@ > * running jobs equals the maximum allowed or > * (2) a job can only be run locally, but > * nLocal equals maxLocal */ >-#ifndef RMT_WILL_WATCH > #ifdef USE_KQUEUE > static int kqfd; /* File descriptor obtained by kqueue() */ > #else > static fd_set outputs; /* Set of descriptors of pipes > connected to > * the output channels of children */ > #endif >-#endif > > STATIC GNode *lastNode; /* The node for which output was > most recently > * produced. */ >@@ -254,15 +248,9 @@ > * job when it's not the most-recent job heard > * from */ > >-#ifdef REMOTE >-# define TARG_FMT "--- %s at %s ---\n" /* Default format */ >-# define MESSAGE(fp, gn) \ >- (void) fprintf(fp, targFmt, gn->name, gn->rem.hname); >-#else >-# define TARG_FMT "--- %s ---\n" /* Default format */ >-# define MESSAGE(fp, gn) \ >+#define TARG_FMT "--- %s ---\n" /* Default format */ >+#define MESSAGE(fp, gn) \ > (void) fprintf(fp, targFmt, gn->name); >-#endif > > /* > * When JobStart attempts to run a job remotely but can't, and isn't allowed >@@ -311,15 +299,8 @@ > static int JobPrintCommand(void *, void *); > static int JobSaveCommand(void *, void *); > static void JobClose(Job *); >-#ifdef REMOTE >-static int JobCmpRmtID(Job *, int); >-# ifdef RMT_WILL_WATCH >-static void JobLocalInput(int, Job *); >-# endif >-#else > static void JobFinish(Job *, int *); > static void JobExec(Job *, char **); >-#endif > static void JobMakeArgv(Job *, char **); > static void JobRestart(Job *); > static int JobStart(GNode *, int, Job *); >@@ -348,20 +329,13 @@ > { > Job *job = (Job *) jobp; > int signo = *(int *) signop; >-#ifdef RMT_WANTS_SIGNALS >- if (job->flags & JOB_REMOTE) { >- (void) Rmt_Signal(job, signo); >- } else { >- KILL(job->pid, signo); >- } >-#else >+ > /* > * Assume that sending the signal to job->pid will signal any remote > * job as well. > */ > DEBUGF(JOB, ("JobCondPassSig passing signal %d to child %d.\n", > signo, job->pid)); > KILL(job->pid, signo); >-#endif > return 0; > } > >@@ -454,27 +428,6 @@ > return *(int *) pid - ((Job *) job)->pid; > } > >-#ifdef REMOTE >-/*- >- *----------------------------------------------------------------------- >- * JobCmpRmtID -- >- * Compare the rmtID of the job with the given rmtID and return 0 if they >- * are equal. >- * >- * Results: >- * 0 if the rmtID's match >- * >- * Side Effects: >- * None. >- *----------------------------------------------------------------------- >- */ >-static int >-JobCmpRmtID(void *job, void *rmtID) >-{ >- return(*(int *) rmtID - *(int *) job->rmtID); >-} >-#endif >- > /*- > *----------------------------------------------------------------------- > * JobPrintCommand -- >@@ -702,9 +655,7 @@ > JobClose(Job *job) > { > if (usePipes) { >-#ifdef RMT_WILL_WATCH >- Rmt_Ignore(job->inPipe); >-#elif !defined(USE_KQUEUE) >+#if !defined(USE_KQUEUE) > FD_CLR(job->inPipe, &outputs); > #endif > if (job->outPipe != job->inPipe) { >@@ -759,18 +710,11 @@ > * cases, finish out the job's output before printing the exit > * status... > */ >-#ifdef REMOTE >- KILL(job->pid, SIGCONT); >-#endif > JobClose(job); > if (job->cmdFILE != NULL && job->cmdFILE != stdout) { > (void) fclose(job->cmdFILE); > } > done = TRUE; >-#ifdef REMOTE >- if (job->flags & JOB_REMOTE) >- Rmt_Done(job->rmtID, job->node); >-#endif > } else if (WIFEXITED(*status)) { > /* > * Deal with ignored errors in -B mode. We need to print a message >@@ -787,10 +731,6 @@ > * stuff? > */ > JobClose(job); >-#ifdef REMOTE >- if (job->flags & JOB_REMOTE) >- Rmt_Done(job->rmtID, job->node); >-#endif /* REMOTE */ > } else { > /* > * No need to close things down or anything. >@@ -851,10 +791,6 @@ > } > job->flags |= JOB_RESUME; > (void)Lst_AtEnd(stoppedJobs, (void *)job); >-#ifdef REMOTE >- if (job->flags & JOB_REMIGRATE) >- JobRestart(job); >-#endif > (void) fflush(out); > return; > } else if (WTERMSIG(*status) == SIGCONT) { >@@ -1120,27 +1056,6 @@ > } > return TRUE; > } >-#ifdef RMT_WILL_WATCH >-/*- >- *----------------------------------------------------------------------- >- * JobLocalInput -- >- * Handle a pipe becoming readable. Callback function for Rmt_Watch >- * >- * Results: >- * None >- * >- * Side Effects: >- * JobDoOutput is called. >- * >- *----------------------------------------------------------------------- >- */ >-/*ARGSUSED*/ >-static void >-JobLocalInput(int stream, Job *job) >-{ >- JobDoOutput(job, FALSE); >-} >-#endif /* RMT_WILL_WATCH */ > > /*- > *----------------------------------------------------------------------- >@@ -1186,12 +1101,6 @@ > lastNode = job->node; > } > >-#ifdef RMT_NO_EXEC >- if (job->flags & JOB_REMOTE) { >- goto jobExecFinish; >- } >-#endif /* RMT_NO_EXEC */ >- > if ((cpid = vfork()) == -1) { > Punt("Cannot fork"); > } else if (cpid == 0) { >@@ -1245,20 +1154,12 @@ > # endif > #endif /* USE_PGRP */ > >-#ifdef REMOTE >- if (job->flags & JOB_REMOTE) { >- Rmt_Exec(shellPath, argv, FALSE); >- } else >-#endif /* REMOTE */ >- (void) execv(shellPath, argv); >+ (void) execv(shellPath, argv); > > (void) write(STDERR_FILENO, "Could not execute shell\n", > sizeof("Could not execute shell")); > _exit(1); > } else { >-#ifdef REMOTE >- long omask = sigblock(sigmask(SIGCHLD)); >-#endif > job->pid = cpid; > > if (usePipes && (job->flags & JOB_FIRST) ) { >@@ -1272,9 +1173,7 @@ > #endif > job->curPos = 0; > >-#ifdef RMT_WILL_WATCH >- Rmt_Watch(job->inPipe, JobLocalInput, job); >-#elif defined(USE_KQUEUE) >+#if defined(USE_KQUEUE) > EV_SET(&kev[0], job->inPipe, EVFILT_READ, EV_ADD, 0, 0, job); > EV_SET(&kev[1], job->pid, EVFILT_PROC, EV_ADD | EV_ONESHOT, > NOTE_EXIT, 0, NULL); >@@ -1285,15 +1184,11 @@ > } > #else > FD_SET(job->inPipe, &outputs); >-#endif /* RMT_WILL_WATCH */ >+#endif /* USE_KQUEUE */ > } > > if (job->flags & JOB_REMOTE) { >-#ifndef REMOTE > job->rmtID = 0; >-#else >- job->rmtID = Rmt_LastID(job->pid); >-#endif /* REMOTE */ > } else { > nLocal += 1; > /* >@@ -1304,14 +1199,8 @@ > job->cmdFILE = NULL; > } > } >-#ifdef REMOTE >- (void) sigsetmask(omask); >-#endif > } > >-#ifdef RMT_NO_EXEC >-jobExecFinish: >-#endif > /* > * Now the job is actually running, add it to the table. > */ >@@ -1391,80 +1280,41 @@ > static void > JobRestart(Job *job) > { >-#ifdef REMOTE >- int host; >-#endif > > if (job->flags & JOB_REMIGRATE) { >- if ( >-#ifdef REMOTE >- verboseRemigrates || >-#endif >- DEBUG(JOB)) { >+ if (DEBUG(JOB)) { > (void) fprintf(stdout, "*** remigrating %x(%s)\n", > job->pid, job->node->name); > (void) fflush(stdout); > } > >-#ifdef REMOTE >- if (!Rmt_ReExport(job->pid, job->node, &host)) { >- if (verboseRemigrates || DEBUG(JOB)) { >- (void) fprintf(stdout, "*** couldn't migrate...\n"); >+ if (nLocal != maxLocal) { >+ /* >+ * Job cannot be remigrated, but there's room on the local >+ * machine, so resume the job and note that another >+ * local job has started. >+ */ >+ if (DEBUG(JOB)) { >+ (void) fprintf(stdout, "*** resuming on local machine\n"); > (void) fflush(stdout); > } >-#endif >- if (nLocal != maxLocal) { >- /* >- * Job cannot be remigrated, but there's room on the local >- * machine, so resume the job and note that another >- * local job has started. >- */ >- if ( >-#ifdef REMOTE >- verboseRemigrates || >-#endif >- DEBUG(JOB)) { >- (void) fprintf(stdout, "*** resuming on local machine\n"); >- (void) fflush(stdout); >- } >- KILL(job->pid, SIGCONT); >- nLocal +=1; >-#ifdef REMOTE >- job->flags &= ~(JOB_REMIGRATE|JOB_RESUME|JOB_REMOTE); >- job->flags |= JOB_CONTINUING; >-#else >- job->flags &= ~(JOB_REMIGRATE|JOB_RESUME); >-#endif >- } else { >- /* >- * Job cannot be restarted. Mark the table as full and >- * place the job back on the list of stopped jobs. >- */ >- if ( >-#ifdef REMOTE >- verboseRemigrates || >-#endif >- DEBUG(JOB)) { >- (void) fprintf(stdout, "*** holding\n"); >- (void) fflush(stdout); >- } >- (void)Lst_AtFront(stoppedJobs, (void *)job); >- jobFull = TRUE; >- DEBUGF(JOB, ("Job queue is full.\n")); >- return; >- } >-#ifdef REMOTE >+ KILL(job->pid, SIGCONT); >+ nLocal +=1; >+ job->flags &= ~(JOB_REMIGRATE|JOB_RESUME); > } else { > /* >- * Clear out the remigrate and resume flags. Set the continuing >- * flag so we know later on that the process isn't exiting just >- * because of a signal. >+ * Job cannot be restarted. Mark the table as full and >+ * place the job back on the list of stopped jobs. > */ >- job->flags &= ~(JOB_REMIGRATE|JOB_RESUME); >- job->flags |= JOB_CONTINUING; >- job->rmtID = host; >+ if (DEBUG(JOB)) { >+ (void) fprintf(stdout, "*** holding\n"); >+ (void) fflush(stdout); >+ } >+ (void)Lst_AtFront(stoppedJobs, (void *)job); >+ jobFull = TRUE; >+ DEBUGF(JOB, ("Job queue is full.\n")); >+ return; > } >-#endif > > (void)Lst_AtEnd(jobs, (void *)job); > nJobs += 1; >@@ -1486,43 +1336,23 @@ > JobMakeArgv(job, argv); > > DEBUGF(JOB, ("Restarting %s...", job->node->name)); >-#ifdef REMOTE >- if ((job->node->type&OP_NOEXPORT) || >- (nLocal < maxLocal && runLocalFirst) >-# ifdef RMT_NO_EXEC >- || !Rmt_Export(shellPath, argv, job) >-# else >- || !Rmt_Begin(shellPath, argv, job->node) >-# endif >-#endif >- { >- if (((nLocal >= maxLocal) && !(job->flags & JOB_SPECIAL))) { >- /* >- * Can't be exported and not allowed to run locally -- put it >- * back on the hold queue and mark the table full >- */ >- DEBUGF(JOB, ("holding\n")); >- (void)Lst_AtFront(stoppedJobs, (void *)job); >- jobFull = TRUE; >- DEBUGF(JOB, ("Job queue is full.\n")); >- return; >- } else { >- /* >- * Job may be run locally. >- */ >- DEBUGF(JOB, ("running locally\n")); >- job->flags &= ~JOB_REMOTE; >- } >- } >-#ifdef REMOTE >- else { >+ if (((nLocal >= maxLocal) && !(job->flags & JOB_SPECIAL))) { >+ /* >+ * Can't be exported and not allowed to run locally -- put it >+ * back on the hold queue and mark the table full >+ */ >+ DEBUGF(JOB, ("holding\n")); >+ (void)Lst_AtFront(stoppedJobs, (void *)job); >+ jobFull = TRUE; >+ DEBUGF(JOB, ("Job queue is full.\n")); >+ return; >+ } else { > /* >- * Can be exported. Hooray! >+ * Job may be run locally. > */ >- DEBUGF(JOB, ("exporting\n")); >- job->flags |= JOB_REMOTE; >+ DEBUGF(JOB, ("running locally\n")); >+ job->flags &= ~JOB_REMOTE; > } >-#endif > JobExec(job, argv); > } else { > /* >@@ -1532,14 +1362,8 @@ > DEBUGF(JOB, ("Resuming %s...", job->node->name)); > if (((job->flags & JOB_REMOTE) || > (nLocal < maxLocal) || >-#ifdef REMOTE >- (((job->flags & JOB_SPECIAL) && >- (job->node->type & OP_NOEXPORT)) && >- (maxLocal == 0))) && >-#else > ((job->flags & JOB_SPECIAL) && > (maxLocal == 0))) && >-#endif > (nJobs != maxJobs)) > { > /* >@@ -1552,12 +1376,7 @@ > Boolean error; > int status; > >-#ifdef RMT_WANTS_SIGNALS >- if (job->flags & JOB_REMOTE) { >- error = !Rmt_Signal(job, SIGCONT); >- } else >-#endif /* RMT_WANTS_SIGNALS */ >- error = (KILL(job->pid, SIGCONT) != 0); >+ error = (KILL(job->pid, SIGCONT) != 0); > > if (!error) { > /* >@@ -1839,27 +1658,11 @@ > } > } > >-#ifdef REMOTE >- if (!(gn->type & OP_NOEXPORT) && !(runLocalFirst && nLocal < maxLocal)) { >-#ifdef RMT_NO_EXEC >- local = !Rmt_Export(shellPath, argv, job); >-#else >- local = !Rmt_Begin(shellPath, argv, job->node); >-#endif /* RMT_NO_EXEC */ >- if (!local) { >- job->flags |= JOB_REMOTE; >- } >- } else >-#endif >- local = TRUE; >+ local = TRUE; > > if (local && (((nLocal >= maxLocal) && > !(job->flags & JOB_SPECIAL) && >-#ifdef REMOTE >- (!(gn->type & OP_NOEXPORT) || (maxLocal != 0)) >-#else > (maxLocal != 0) >-#endif > ))) > { > /* >@@ -2192,14 +1995,7 @@ > nJobs -= 1; > DEBUGF(JOB, ("Job queue is no longer full.\n")); > jobFull = FALSE; >-#ifdef REMOTE >- if (!(job->flags & JOB_REMOTE)) { >- DEBUGF(JOB, ("Job queue has one fewer local process.\n")); >- nLocal -= 1; >- } >-#else > nLocal -= 1; >-#endif > } > > JobFinish(job, &status); >@@ -2236,34 +2032,9 @@ > LstNode ln; > Job *job; > #endif >-#ifdef RMT_WILL_WATCH >- int pnJobs; /* Previous nJobs */ >-#endif > > (void) fflush(stdout); >-#ifdef RMT_WILL_WATCH >- pnJobs = nJobs; > >- /* >- * It is possible for us to be called with nJobs equal to 0. This happens >- * if all the jobs finish and a job that is stopped cannot be run >- * locally (eg if maxLocal is 0) and cannot be exported. The job will >- * be placed back on the stoppedJobs queue, Job_Empty() will return >false, >- * Make_Run will call us again when there's nothing for which to wait. >- * nJobs never changes, so we loop forever. Hence the check. It could >- * be argued that we should sleep for a bit so as not to swamp the >- * exportation system with requests. Perhaps we should. >- * >- * NOTE: IT IS THE RESPONSIBILITY OF Rmt_Wait TO CALL Job_CatchChildren >- * IN A TIMELY FASHION TO CATCH ANY LOCALLY RUNNING JOBS THAT EXIT. >- * It may use the variable nLocal to determine if it needs to call >- * Job_CatchChildren (if nLocal is 0, there's nothing for which to >- * wait...) >- */ >- while (nJobs != 0 && pnJobs == nJobs) { >- Rmt_Wait(); >- } >-#else > if (usePipes) { > #ifdef USE_KQUEUE > if ((nfds = kevent(kqfd, NULL, 0, kev, KEV_SIZE, NULL)) == -1) { >@@ -2309,7 +2080,6 @@ > } > #endif /* !USE_KQUEUE */ > } >-#endif /* RMT_WILL_WATCH */ > } > > /*- >@@ -2379,11 +2149,7 @@ > > lastNode = NULL; > >- if (maxJobs == 1 || beVerbose == 0 >-#ifdef REMOTE >- || noMessages >-#endif >- ) { >+ if (maxJobs == 1 || beVerbose == 0) { > /* > * If only one job can run at a time, there's no need for a banner, > * no is there? >@@ -2423,7 +2189,7 @@ > * we're giving each job its own process group (since then it won't get > * signals from the terminal driver as we own the terminal) > */ >-#if defined(RMT_WANTS_SIGNALS) || defined(USE_PGRP) >+#if defined(USE_PGRP) > if (signal(SIGTSTP, SIG_IGN) != SIG_IGN) { > (void) signal(SIGTSTP, JobPassSig); > } >@@ -2450,9 +2216,7 @@ > JobStart(begin, JOB_SPECIAL, (Job *)0); > while (nJobs) { > Job_CatchOutput(); >-#ifndef RMT_WILL_WATCH > Job_CatchChildren(!usePipes); >-#endif /* RMT_WILL_WATCH */ > } > } > postCommands = Targ_FindNode(".END", TARG_CREATE); >@@ -2757,80 +2521,13 @@ > Error("*** %s removed", file); > } > } >-#ifdef RMT_WANTS_SIGNALS >- if (job->flags & JOB_REMOTE) { >- /* >- * If job is remote, let the Rmt module do the killing. >- */ >- if (!Rmt_Signal(job, signo)) { >- /* >- * If couldn't kill the thing, finish it out now with an >- * error code, since no exit report will come in likely. >- */ >- int status; >- >- status.w_status = 0; >- status.w_retcode = 1; >- JobFinish(job, &status); >- } >- } else if (job->pid) { >- KILL(job->pid, signo); >- } >-#else > if (job->pid) { > DEBUGF(JOB, ("JobInterrupt passing signal to child %d.\n", > job->pid)); > KILL(job->pid, signo); > } >-#endif /* RMT_WANTS_SIGNALS */ > } > >-#ifdef REMOTE >- (void)Lst_Open(stoppedJobs); >- while ((ln = Lst_Next(stoppedJobs)) != NULL) { >- job = (Job *) Lst_Datum(ln); >- >- if (job->flags & JOB_RESTART) { >- DEBUGF(JOB, "JobInterrupt skipping job on stopped queue" >- "-- it was waiting to be restarted.\n"); >- continue; >- } >- if (!Targ_Precious(job->node)) { >- char *file = (job->node->path == NULL ? >- job->node->name : >- job->node->path); >- if (eunlink(file) == 0) { >- Error("*** %s removed", file); >- } >- } >- /* >- * Resume the thing so it will take the signal. >- */ >- DEBUGF(JOB, ("JobInterrupt passing CONT to stopped child %d.\n", >job->pid)); >- KILL(job->pid, SIGCONT); >-#ifdef RMT_WANTS_SIGNALS >- if (job->flags & JOB_REMOTE) { >- /* >- * If job is remote, let the Rmt module do the killing. >- */ >- if (!Rmt_Signal(job, SIGINT)) { >- /* >- * If couldn't kill the thing, finish it out now with an >- * error code, since no exit report will come in likely. >- */ >- int status; >- status.w_status = 0; >- status.w_retcode = 1; >- JobFinish(job, &status); >- } >- } else if (job->pid) { >- DEBUGF(JOB, "JobInterrupt passing interrupt to stopped child >%d.\n", >- job->pid); >- KILL(job->pid, SIGINT); >- } >-#endif /* RMT_WANTS_SIGNALS */ >- } >-#endif > Lst_Close(stoppedJobs); > > if (runINTERRUPT && !touchFlag) { >@@ -2841,9 +2538,7 @@ > JobStart(interrupt, JOB_IGNDOTS, (Job *)0); > while (nJobs) { > Job_CatchOutput(); >-#ifndef RMT_WILL_WATCH > Job_CatchChildren(!usePipes); >-#endif /* RMT_WILL_WATCH */ > } > } > } >@@ -2870,9 +2565,7 @@ > > while (nJobs) { > Job_CatchOutput(); >-#ifndef RMT_WILL_WATCH > Job_CatchChildren(!usePipes); >-#endif /* RMT_WILL_WATCH */ > } > } > } >@@ -2899,9 +2592,7 @@ > aborting = ABORT_WAIT; > while (nJobs != 0) { > Job_CatchOutput(); >-#ifndef RMT_WILL_WATCH > Job_CatchChildren(!usePipes); >-#endif /* RMT_WILL_WATCH */ > } > aborting = 0; > } >@@ -2939,18 +2630,8 @@ > * kill the child process with increasingly drastic signals > to make > * darn sure it's dead. > */ >-#ifdef RMT_WANTS_SIGNALS >- if (job->flags & JOB_REMOTE) { >- Rmt_Signal(job, SIGINT); >- Rmt_Signal(job, SIGKILL); >- } else { >- KILL(job->pid, SIGINT); >- KILL(job->pid, SIGKILL); >- } >-#else > KILL(job->pid, SIGINT); > KILL(job->pid, SIGKILL); >-#endif /* RMT_WANTS_SIGNALS */ > } > } > >@@ -2961,51 +2642,6 @@ > continue; > } > >-#ifdef REMOTE >-/*- >- *----------------------------------------------------------------------- >- * JobFlagForMigration -- >- * Handle the eviction of a child. Called from RmtStatusChange. >- * Flags the child as remigratable and then suspends it. Takes >- * the ID of the host we used, for matching children. >- * >- * Results: >- * none. >- * >- * Side Effects: >- * The job descriptor is flagged for remigration. >- * >- *----------------------------------------------------------------------- >- */ >-void >-JobFlagForMigration(int hostID) >-{ >- Job *job; /* job descriptor for dead child */ >- LstNode jnode; /* list element for finding job */ >- >- DEBUGF(JOB, ("JobFlagForMigration(%d) called.\n", hostID)); >- jnode = Lst_Find(jobs, (void *)hostID, JobCmpRmtID); >- >- if (jnode == NULL) { >- jnode = Lst_Find(stoppedJobs, (void *)hostID, JobCmpRmtID); >- if (jnode == NULL) { >- if (DEBUG(JOB)) { >- Error("Evicting host(%d) not in table", hostID); >- } >- return; >- } >- } >- job = (Job *) Lst_Datum(jnode); >- >- DEBUGF(JOB, ("JobFlagForMigration(%d) found job '%s'.\n", hostID, >job->node->name)); >- >- KILL(job->pid, SIGSTOP); >- >- job->flags |= JOB_REMIGRATE; >-} >- >-#endif >- > /*- > *----------------------------------------------------------------------- > * JobRestartJobs -- >Index: job.h >=================================================================== >RCS file: /local/cvs/freebsd/src/usr.bin/make/job.h,v >retrieving revision 1.22 >diff -u -r1.22 job.h >--- job.h 23 Oct 2004 21:34:41 -0000 1.22 >+++ job.h 2 Nov 2004 09:20:39 -0000 >@@ -207,28 +207,6 @@ > > extern char *shellPath; > extern char *shellName; >- >-/* >- * If REMOTE is defined then these things need exposed, otherwise they are >- * static to job.c! >- */ >-#ifdef REMOTE >-extern char *targFmt; /* Format string for banner that separates >- * output from multiple jobs. Contains a >- * single %s where the name of the node being >- * made should be put. */ >-extern GNode *lastNode; /* Last node for which a banner was printed. >- * If Rmt module finds it necessary to print >- * a banner, it should set this to the node >- * for which the banner was printed */ >-extern int nJobs; /* Number of jobs running (local and >remote) */ >-extern int nLocal; /* Number of jobs running locally */ >-extern Lst jobs; /* List of active job descriptors */ >-extern Lst stoppedJobs; /* List of jobs that are stopped or didn't >- * quite get started */ >-extern Boolean jobFull; /* Non-zero if no more jobs should/will >start*/ >-#endif >- > extern int maxJobs; /* Number of jobs that may run */ > > >Index: main.c >=================================================================== >RCS file: /local/cvs/freebsd/src/usr.bin/make/main.c,v >retrieving revision 1.92 >diff -u -r1.92 main.c >--- main.c 23 Oct 2004 21:34:41 -0000 1.92 >+++ main.c 2 Nov 2004 09:19:51 -0000 >@@ -168,11 +168,7 @@ > int c; > > optind = 1; /* since we're called more than once */ >-#ifdef REMOTE >-# define OPTFLAGS "BC:D:E:I:L:PSV:Xd:ef:ij:km:nqrstv" >-#else >-# define OPTFLAGS "BC:D:E:I:PSV:Xd:ef:ij:km:nqrstv" >-#endif >+#define OPTFLAGS "BC:D:E:I:PSV:Xd:ef:ij:km:nqrstv" > rearg: while((c = getopt(argc, argv, OPTFLAGS)) != -1) { > switch(c) { > case 'C': >@@ -198,20 +194,6 @@ > compatMake = TRUE; > MFLAGS_append("-B", NULL); > break; >-#ifdef REMOTE >- case 'L': { >- char *endptr; >- >- maxLocal = strtol(optarg, &endptr, 10); >- if (maxLocal < 0 || *endptr != '\0') { >- warnx("illegal number, -L argument -- %s", >- optarg); >- usage(); >- } >- MFLAGS_append("-L", optarg); >- break; >- } >-#endif > case 'P': > usePipes = FALSE; > MFLAGS_append("-P", NULL); >@@ -302,9 +284,7 @@ > optarg); > usage(); > } >-#ifndef REMOTE > maxLocal = maxJobs; >-#endif > MFLAGS_append("-j", optarg); > break; > } >@@ -599,11 +579,7 @@ > jobsRunning = FALSE; > > maxLocal = DEFMAXLOCAL; /* Set default local max > concurrency */ >-#ifdef REMOTE >- maxJobs = DEFMAXJOBS; /* Set default max concurrency */ >-#else > maxJobs = maxLocal; >-#endif > forceJobs = FALSE; /* No -j flag */ > compatMake = FALSE; /* No compat mode */ > >_______________________________________________ >freebsd-arch@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-arch >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 08:44:48 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 871A516A4D5 for ; Thu, 4 Nov 2004 08:44:48 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAE9C43D41 for ; Thu, 4 Nov 2004 08:44:47 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iA48ijA5039211 for ; Thu, 4 Nov 2004 09:44:45 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Thu, 04 Nov 2004 09:44:45 +0100 Message-ID: <39210.1099557885@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 08:44:48 -0000 We increasingly need better granularity in our sleep/wakeup calls and things like device polling and trafic shaping needs higher granularity in particular. So pending any really good arguments to the contrary I plan to increase HZ to 1000 on i386 this weekend. You can still define any HZ value you like in your kernel config file or even set it from the loader. -- 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-arch@FreeBSD.ORG Thu Nov 4 08:48:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3AB016A4CE for ; Thu, 4 Nov 2004 08:48:11 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF1C443D5A for ; Thu, 4 Nov 2004 08:48:11 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id iA48mBLK057948; Thu, 4 Nov 2004 00:48:11 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id iA48mBwb057947; Thu, 4 Nov 2004 00:48:11 -0800 (PST) (envelope-from rizzo) Date: Thu, 4 Nov 2004 00:48:11 -0800 From: Luigi Rizzo To: Poul-Henning Kamp Message-ID: <20041104004811.A57935@xorpc.icir.org> References: <39210.1099557885@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <39210.1099557885@critter.freebsd.dk>; from phk@phk.freebsd.dk on Thu, Nov 04, 2004 at 09:44:45AM +0100 cc: arch@freebsd.org Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 08:48:11 -0000 On Thu, Nov 04, 2004 at 09:44:45AM +0100, Poul-Henning Kamp wrote: > > We increasingly need better granularity in our sleep/wakeup calls and > things like device polling and trafic shaping needs higher granularity > in particular. are you trying to put the blame on me ? :) cheers luigi > So pending any really good arguments to the contrary I plan to increase > HZ to 1000 on i386 this weekend. > > You can still define any HZ value you like in your kernel config file > or even set it from the loader. > > -- > 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. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 08:50:27 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD82C16A4CF for ; Thu, 4 Nov 2004 08:50:27 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 893D643D1F for ; Thu, 4 Nov 2004 08:50:16 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iA48oFI0039431; Thu, 4 Nov 2004 09:50:15 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Luigi Rizzo From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 04 Nov 2004 00:48:11 PST." <20041104004811.A57935@xorpc.icir.org> Date: Thu, 04 Nov 2004 09:50:15 +0100 Message-ID: <39430.1099558215@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 08:50:27 -0000 In message <20041104004811.A57935@xorpc.icir.org>, Luigi Rizzo writes: >On Thu, Nov 04, 2004 at 09:44:45AM +0100, Poul-Henning Kamp wrote: >> >> We increasingly need better granularity in our sleep/wakeup calls and >> things like device polling and trafic shaping needs higher granularity >> in particular. > >are you trying to put the blame on me ? :) No, but I can do it if you want me to :-) Seriously, this is just long overdue, we've been talking about it since the 4.x branch. -- 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-arch@FreeBSD.ORG Wed Nov 3 19:00:02 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A65C16A4CE for ; Wed, 3 Nov 2004 19:00:02 +0000 (GMT) Received: from exch2.verniernetworks.com (dns.verniernetworks.com [65.200.185.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id D740E43D3F for ; Wed, 3 Nov 2004 19:00:01 +0000 (GMT) (envelope-from adazzi@verniernetworks.com) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Nov 2004 11:00:01 -0800 Message-ID: <085485A8ADCB4B49874A54D6185A21FD618834@exch2.verniernetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VIA c3 support Thread-Index: AcTB11JHyK0+T9h7TXaUTj3bhddqMw== X-Priority: 1 Priority: Urgent Importance: high From: "Alain Dazzi" To: X-Mailman-Approved-At: Thu, 04 Nov 2004 13:14:54 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: VIA c3 support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2004 19:00:02 -0000 Does FreeBSD 5.3 support the VIA C3 processor? =20 Thanks! =20 -Alain From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 14:06:45 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E97F16A4CE for ; Thu, 4 Nov 2004 14:06:45 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D62343D54 for ; Thu, 4 Nov 2004 14:06:45 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iA4E5ptB031234; Thu, 4 Nov 2004 09:05:51 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iA4E5jw5031231; Thu, 4 Nov 2004 09:05:51 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 4 Nov 2004 09:05:45 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <39210.1099557885@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 14:06:45 -0000 On Thu, 4 Nov 2004, Poul-Henning Kamp wrote: > We increasingly need better granularity in our sleep/wakeup calls and > things like device polling and trafic shaping needs higher granularity > in particular. > > So pending any really good arguments to the contrary I plan to increase > HZ to 1000 on i386 this weekend. I don't object to increasing HZ, but will note that it results in a slight increase in overhead relative to lower values on the same hadware. It was observed to me, however, that with modern CPUs, running HZ ten times faster still results in a less overhead than on older processors with the slower HZ, so... :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > > You can still define any HZ value you like in your kernel config file > or even set it from the loader. > > -- > 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. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 14:15:25 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E3E216A4CE; Thu, 4 Nov 2004 14:15:25 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33E8543D46; Thu, 4 Nov 2004 14:15:25 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id iA4EFPlW061700; Thu, 4 Nov 2004 06:15:25 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id iA4EFNDQ061699; Thu, 4 Nov 2004 06:15:23 -0800 (PST) (envelope-from rizzo) Date: Thu, 4 Nov 2004 06:15:23 -0800 From: Luigi Rizzo To: Robert Watson Message-ID: <20041104061523.C61484@xorpc.icir.org> References: <39210.1099557885@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rwatson@freebsd.org on Thu, Nov 04, 2004 at 09:05:45AM -0500 cc: arch@freebsd.org cc: Poul-Henning Kamp Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 14:15:25 -0000 On Thu, Nov 04, 2004 at 09:05:45AM -0500, Robert Watson wrote: ... > I don't object to increasing HZ, but will note that it results in a slight > increase in overhead relative to lower values on the same hadware. It was > observed to me, however, that with modern CPUs, running HZ ten times > faster still results in a less overhead than on older processors with the > slower HZ, so... :-) ok, my turn to say something obvious... lets see... "I will note that HZ=1000 is ten time higher than HZ=100," nah, he just said that; how about this... "modern CPUs are much faster than older processors" no, he said that too... hmmmm... "i don't object to the change" no, what's the point to speak if i agree... ok i give up, i have nothing to say on the subject, but one cannot always be serious... :) cheers luigi > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Principal Research Scientist, McAfee Research > > > > > > You can still define any HZ value you like in your kernel config file > > or even set it from the loader. > > > > -- > > 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. > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 14:24:33 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBC9B16A4CE for ; Thu, 4 Nov 2004 14:24:33 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A4ED43D49 for ; Thu, 4 Nov 2004 14:24:33 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iA4EQSHX025678; Thu, 4 Nov 2004 07:26:28 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <418A3BE3.8080807@freebsd.org> Date: Thu, 04 Nov 2004 07:25:39 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <39210.1099557885@critter.freebsd.dk> In-Reply-To: <39210.1099557885@critter.freebsd.dk> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 14:24:33 -0000 Poul-Henning Kamp wrote: > We increasingly need better granularity in our sleep/wakeup calls and > things like device polling and trafic shaping needs higher granularity > in particular. > > So pending any really good arguments to the contrary I plan to increase > HZ to 1000 on i386 this weekend. > > You can still define any HZ value you like in your kernel config file > or even set it from the loader. > Sounds like a good plan. Scott From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 16:23:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 622D616A4CE for ; Thu, 4 Nov 2004 16:23:14 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4D9743D46 for ; Thu, 4 Nov 2004 16:23:13 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 8EA075310; Thu, 4 Nov 2004 17:23:12 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id D26395314; Thu, 4 Nov 2004 17:23:05 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id AF3F3B85E; Thu, 4 Nov 2004 17:23:05 +0100 (CET) To: Poul-Henning Kamp References: <39210.1099557885@critter.freebsd.dk> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 04 Nov 2004 17:23:05 +0100 In-Reply-To: <39210.1099557885@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 04 Nov 2004 09:44:45 +0100") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 cc: arch@freebsd.org Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 16:23:14 -0000 Poul-Henning Kamp writes: > So pending any really good arguments to the contrary I plan to increase > HZ to 1000 on i386 this weekend. two good arguments: 1) I'm already working on this, and you know it, since I asked you about it in Karlsruhe. 2) 1000 is not a good choice, because we can't approximate it well with the 8254. 1268 is better, 1381 is even better, 1903 is the best we can do between 1000 and 2000, 2299 is the best we can do between 1000 and 5000. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 16:32:13 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F81816A4CE for ; Thu, 4 Nov 2004 16:32:13 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA23943D39 for ; Thu, 4 Nov 2004 16:32:12 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iA4GWAQu048556; Thu, 4 Nov 2004 17:32:10 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 04 Nov 2004 17:23:05 +0100." Date: Thu, 04 Nov 2004 17:32:10 +0100 Message-ID: <48555.1099585930@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 16:32:13 -0000 In message , =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= writes: >Poul-Henning Kamp writes: >> So pending any really good arguments to the contrary I plan to increase >> HZ to 1000 on i386 this weekend. > >two good arguments: > > 1) I'm already working on this, and you know it, since I asked you > about it in Karlsruhe. Ahh, sorry, I got the impression that you were not going to do it on your own. > 2) 1000 is not a good choice, because we can't approximate it well > with the 8254. 1268 is better, 1381 is even better, 1903 is the > best we can do between 1000 and 2000, 2299 is the best we can do > between 1000 and 5000. I played with it here and found that 1000 actually works better than 941. (1193182 / 941 ~= 1268) because the 941 gives a slow beat against 1Hz. It is actually preferable to have a fast beat (jitter) than a slow beat (wander), particularly for people doing benchmarks. Poul-Henning -- 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-arch@FreeBSD.ORG Thu Nov 4 16:34:58 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AADD416A4CE for ; Thu, 4 Nov 2004 16:34:58 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E8D843D45 for ; Thu, 4 Nov 2004 16:34:58 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iA4Gapcd026293; Thu, 4 Nov 2004 09:36:51 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <418A5A72.6020700@freebsd.org> Date: Thu, 04 Nov 2004 09:36:02 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <48555.1099585930@critter.freebsd.dk> In-Reply-To: <48555.1099585930@critter.freebsd.dk> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= cc: arch@freebsd.org Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 16:34:58 -0000 Poul-Henning Kamp wrote: > In message , =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= writes: > >>Poul-Henning Kamp writes: >> >>>So pending any really good arguments to the contrary I plan to increase >>>HZ to 1000 on i386 this weekend. >> >>two good arguments: >> >> 1) I'm already working on this, and you know it, since I asked you >> about it in Karlsruhe. > > > Ahh, sorry, I got the impression that you were not going to do it on > your own. > > >> 2) 1000 is not a good choice, because we can't approximate it well >> with the 8254. 1268 is better, 1381 is even better, 1903 is the >> best we can do between 1000 and 2000, 2299 is the best we can do >> between 1000 and 5000. > > > I played with it here and found that 1000 actually works better than 941. > (1193182 / 941 ~= 1268) because the 941 gives a slow beat against 1Hz. > > It is actually preferable to have a fast beat (jitter) than a slow > beat (wander), particularly for people doing benchmarks. > > Poul-Henning > What timing hardware is used on amd64? Would it suffer there too? Scott From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 16:36:54 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAEA516A4CE; Thu, 4 Nov 2004 16:36:54 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2534A43D41; Thu, 4 Nov 2004 16:36:54 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iA4Gardc048658; Thu, 4 Nov 2004 17:36:53 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Scott Long From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 04 Nov 2004 09:36:02 MST." <418A5A72.6020700@freebsd.org> Date: Thu, 04 Nov 2004 17:36:53 +0100 Message-ID: <48657.1099586213@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= cc: arch@freebsd.org Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 16:36:54 -0000 In message <418A5A72.6020700@freebsd.org>, Scott Long writes: >>> 2) 1000 is not a good choice, because we can't approximate it well >>> with the 8254. 1268 is better, 1381 is even better, 1903 is the >>> best we can do between 1000 and 2000, 2299 is the best we can do >>> between 1000 and 5000. >> >> I played with it here and found that 1000 actually works better than 941. >> (1193182 / 941 ~= 1268) because the 941 gives a slow beat against 1Hz. >> >> It is actually preferable to have a fast beat (jitter) than a slow >> beat (wander), particularly for people doing benchmarks. >> >> Poul-Henning > >What timing hardware is used on amd64? Would it suffer there too? I only tested on i386, but any platform would suffer from this kind of syncronism/syntonism. -- 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-arch@FreeBSD.ORG Thu Nov 4 17:53:16 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6ED716A4CE; Thu, 4 Nov 2004 17:53:16 +0000 (GMT) Received: from mail.net (custpop.ca.mci.com [142.77.1.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12E6643D45; Thu, 4 Nov 2004 17:53:14 +0000 (GMT) (envelope-from kfl@xiphos.ca) Received: from [216.95.199.148] (account kfl@xiphos.ca HELO [192.168.1.7]) by mail.net (CommuniGate Pro SMTP 4.2.5) with ESMTP id 26293856; Thu, 04 Nov 2004 12:53:13 -0500 Message-ID: <418A6FDC.5010204@xiphos.ca> Date: Thu, 04 Nov 2004 13:07:24 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org References: <20041022182430.31A2B1EF3BF@lawyers.icir.org> In-Reply-To: <20041022182430.31A2B1EF3BF@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Marco Molteni cc: freebsd-net@freebsd.org cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 17:53:16 -0000 Hi, I am jumping in here, was too busy to read the list for the last 2 weeks, so please excuse my intrusion. We are using T/TCP in our product line and are very happy with the performance gain. Could you tell me what is the rational for removing T/TCP (security/performances/code complexity, etc ..) from FreeBSD? Again, sorry for being a bit off topic here. Mark Allman wrote: >>A T/TCP alternative as you are describing sounds very >>similar to PR-SCTP (Partial Reliability SCTP). (Don't let the >>name fool you, please read the internet draft). >> >> > >Can you sketch this in a bit more detail? I do not follow. PR-SCTP is >about being allowed to "abandon" data --- i.e., send it and then decide >that you don't really care if it gets across the network (say, because >it got lost and has taken too long to retransmit and so the data is out >of date). Without a Big Hack, I cannot envision TCP doing something >like this. What am I missing? > >Thanks, >allman > > >-- >Mark Allman -- ICIR -- http://www.icir.org/mallman/ > > > > > -- Karim Fodil-Lemelin Lead Programmer Xiphos Technologies Inc. www.xiplink.com From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 18:50:25 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 894EC16A4CF for ; Thu, 4 Nov 2004 18:50:25 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE1CC43D66 for ; Thu, 4 Nov 2004 18:50:24 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 99617 invoked from network); 4 Nov 2004 18:46:28 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Nov 2004 18:46:28 -0000 Message-ID: <418A79F7.15B7CDB9@freebsd.org> Date: Thu, 04 Nov 2004 19:50:31 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Karim Fodil-Lemelin References: <20041022182430.31A2B1EF3BF@lawyers.icir.org> <418A6FDC.5010204@xiphos.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Marco Molteni cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org cc: mallman@icir.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 18:50:25 -0000 Karim Fodil-Lemelin wrote: > > Hi, > > I am jumping in here, was too busy to read the list for the last 2 > weeks, so please excuse my intrusion. We are using T/TCP in our product > line and are very happy with the performance gain. Could you tell me > what is the rational for removing T/TCP (security/performances/code > complexity, etc ..) from FreeBSD? Have a look at the rationale here (and the followup discussion): http://docs.freebsd.org/cgi/mid.cgi?4177C8AD.6060706 And also note that T/TCP was removed only from FreeBSD 6-current. It is still in 4.x and 5.x releases and will not be removed from them. A more secure and much less (code-) intrusive replacement for T/TCP is in the works by me. I'll have code ready soon and it'll be in FreeBSD 6-current probably before christmas along with a proper RFC draft submitted to the IETF TCPM WG. -- Andre From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 19:42:54 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFAE216A4CE for ; Thu, 4 Nov 2004 19:42:54 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFDC443D31 for ; Thu, 4 Nov 2004 19:42:53 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 8CA087A439; Thu, 4 Nov 2004 11:42:53 -0800 (PST) Message-ID: <418A863D.2030809@elischer.org> Date: Thu, 04 Nov 2004 11:42:53 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Poul-Henning Kamp References: <39210.1099557885@critter.freebsd.dk> In-Reply-To: <39210.1099557885@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 19:42:55 -0000 I've been using 1000 by default for a long time.. seems to work fine.. Interstingly, 600 or 1200 are a really good speeds for video Common multiple of 25 Hz (europe TV) 30HZ (North American TV) and 24HZ (cinema film) If we wanted to do good video handling, I'd suggest 1200 as a good option. I've been lookign a bit into a FreeBSD kernel video framework that allows teh clocking in and out of frames at various rates and conversions, and having a 1200 Hz internal clock would be really cool for that.. Of course we could use a dedicated timer if we have one avaliable.. I was playing with the acquire_timer2() (etc) interface to do that but it would be cool to have the default rate be useable :-) Poul-Henning Kamp wrote: >We increasingly need better granularity in our sleep/wakeup calls and >things like device polling and trafic shaping needs higher granularity >in particular. > >So pending any really good arguments to the contrary I plan to increase >HZ to 1000 on i386 this weekend. > >You can still define any HZ value you like in your kernel config file >or even set it from the loader. > > > From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 19:46:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 996F316A4CF for ; Thu, 4 Nov 2004 19:46:35 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E210843D41 for ; Thu, 4 Nov 2004 19:46:34 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iA4JkSUp052132; Thu, 4 Nov 2004 20:46:28 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 04 Nov 2004 11:42:53 PST." <418A863D.2030809@elischer.org> Date: Thu, 04 Nov 2004 20:46:28 +0100 Message-ID: <52131.1099597588@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 19:46:35 -0000 In message <418A863D.2030809@elischer.org>, Julian Elischer writes: >I've been using 1000 by default for a long time.. >seems to work fine.. > >Interstingly, 600 or 1200 are a really good speeds for video There are as mentioned many ways to adjust HZ available so I really think we should just stick with 1000 and let people adjust it if they have to. -- 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-arch@FreeBSD.ORG Thu Nov 4 20:52:41 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC3DD16A4CE; Thu, 4 Nov 2004 20:52:41 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5EFE43D5D; Thu, 4 Nov 2004 20:52:41 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id AF1637A43E; Thu, 4 Nov 2004 12:52:41 -0800 (PST) Message-ID: <418A9699.6050603@elischer.org> Date: Thu, 04 Nov 2004 12:52:41 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Karim Fodil-Lemelin References: <20041022182430.31A2B1EF3BF@lawyers.icir.org> <418A6FDC.5010204@xiphos.ca> In-Reply-To: <418A6FDC.5010204@xiphos.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org cc: Andre Oppermann cc: mallman@icir.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 20:52:42 -0000 Karim Fodil-Lemelin wrote: > Hi, > > I am jumping in here, was too busy to read the list for the last 2 > weeks, so please excuse my intrusion. We are using T/TCP in our > product line and are very happy with the performance gain. Could you > tell me what is the rational for removing T/TCP > (security/performances/code complexity, etc ..) from FreeBSD? > > Again, sorry for being a bit off topic here. what a pitty you didn't notice while it was under discussion: :-( We couldn't find anyone using it... what is your product? From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 20:54:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 236A816A4CE for ; Thu, 4 Nov 2004 20:54:44 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id D06D543D45 for ; Thu, 4 Nov 2004 20:54:43 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 2437 invoked from network); 4 Nov 2004 20:54:43 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 4 Nov 2004 20:54:42 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iA4KsIlG088385; Thu, 4 Nov 2004 15:54:22 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Thu, 4 Nov 2004 14:56:33 -0500 User-Agent: KMail/1.6.2 References: <48555.1099585930@critter.freebsd.dk> <418A5A72.6020700@freebsd.org> In-Reply-To: <418A5A72.6020700@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411041456.33778.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: Poul-Henning Kamp cc: Scott Long cc: arch@FreeBSD.org Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 20:54:44 -0000 On Thursday 04 November 2004 11:36 am, Scott Long wrote: > Poul-Henning Kamp wrote: > > In message , =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= writes: > >>Poul-Henning Kamp writes: > >>>So pending any really good arguments to the contrary I plan to increase > >>>HZ to 1000 on i386 this weekend. > >> > >>two good arguments: > >> > >> 1) I'm already working on this, and you know it, since I asked you > >> about it in Karlsruhe. > > > > Ahh, sorry, I got the impression that you were not going to do it on > > your own. > > > >> 2) 1000 is not a good choice, because we can't approximate it well > >> with the 8254. 1268 is better, 1381 is even better, 1903 is the > >> best we can do between 1000 and 2000, 2299 is the best we can do > >> between 1000 and 5000. > > > > I played with it here and found that 1000 actually works better than 941. > > (1193182 / 941 ~= 1268) because the 941 gives a slow beat against 1Hz. > > > > It is actually preferable to have a fast beat (jitter) than a slow > > beat (wander), particularly for people doing benchmarks. > > > > Poul-Henning > > What timing hardware is used on amd64? Would it suffer there too? Identical to x86 for now. Note that it would be really nice at some point to drive hardclock and statclock via the local APIC timers for SMP on x86 and amd64 so we can stop sending IPIs for each clock interrupt. Alpha uses the per-CPU timers this way already. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 20:54:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B64916A4D1 for ; Thu, 4 Nov 2004 20:54:44 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id D087543D49 for ; Thu, 4 Nov 2004 20:54:43 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 2437 invoked from network); 4 Nov 2004 20:54:43 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 4 Nov 2004 20:54:42 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iA4KsIlG088385; Thu, 4 Nov 2004 15:54:22 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Thu, 4 Nov 2004 14:56:33 -0500 User-Agent: KMail/1.6.2 References: <48555.1099585930@critter.freebsd.dk> <418A5A72.6020700@freebsd.org> In-Reply-To: <418A5A72.6020700@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411041456.33778.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: Poul-Henning Kamp cc: Scott Long cc: arch@FreeBSD.org Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 20:54:44 -0000 On Thursday 04 November 2004 11:36 am, Scott Long wrote: > Poul-Henning Kamp wrote: > > In message , =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= writes: > >>Poul-Henning Kamp writes: > >>>So pending any really good arguments to the contrary I plan to increase > >>>HZ to 1000 on i386 this weekend. > >> > >>two good arguments: > >> > >> 1) I'm already working on this, and you know it, since I asked you > >> about it in Karlsruhe. > > > > Ahh, sorry, I got the impression that you were not going to do it on > > your own. > > > >> 2) 1000 is not a good choice, because we can't approximate it well > >> with the 8254. 1268 is better, 1381 is even better, 1903 is the > >> best we can do between 1000 and 2000, 2299 is the best we can do > >> between 1000 and 5000. > > > > I played with it here and found that 1000 actually works better than 941. > > (1193182 / 941 ~= 1268) because the 941 gives a slow beat against 1Hz. > > > > It is actually preferable to have a fast beat (jitter) than a slow > > beat (wander), particularly for people doing benchmarks. > > > > Poul-Henning > > What timing hardware is used on amd64? Would it suffer there too? Identical to x86 for now. Note that it would be really nice at some point to drive hardclock and statclock via the local APIC timers for SMP on x86 and amd64 so we can stop sending IPIs for each clock interrupt. Alpha uses the per-CPU timers this way already. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 20:58:40 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CA7516A4CE; Thu, 4 Nov 2004 20:58:40 +0000 (GMT) Received: from risky.niblet.co.uk (risky.niblet.co.uk [80.177.236.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF3CB43D41; Thu, 4 Nov 2004 20:58:39 +0000 (GMT) (envelope-from matt@genesi.co.uk) Received: from sakura.niblet.co.uk ([80.177.236.68] helo=sakura) by risky.niblet.co.uk with smtp (Exim 4.42 (FreeBSD)) id 1CPogp-0002Vp-Ur; Thu, 04 Nov 2004 20:58:39 +0000 From: "Matt Sealey" To: "Julian Elischer" , "Karim Fodil-Lemelin" Date: Thu, 4 Nov 2004 20:58:19 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <418A9699.6050603@elischer.org> Importance: Normal cc: freebsd-net@freebsd.org cc: mallman@icir.org cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: RE: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 20:58:40 -0000 His product looks like it's the the product mentioned in the original post by the original poster; http://docs.freebsd.org/cgi/getmsg.cgi?fetch=284774+0+/usr/local/www/db/text/2004/freebsd-net/20041024.freebsd-net QUOTE: However something like T/TCP is certainly useful and I know of one special purpose application using it (Web Proxy Server/Client for high-delay Satellite connections). As long as they can live with FreeBSD 5.3 I don't think it causes a problem whatsoever does it? -- Matt Sealey Genesi, Manager, Developer Relations > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org]On Behalf Of Julian Elischer > Sent: 04 November 2004 20:53 > To: Karim Fodil-Lemelin > Cc: freebsd-net@freebsd.org; freebsd-arch@freebsd.org; Andre Oppermann; > mallman@icir.org > Subject: Re: Removing T/TCP and replacing it with something simpler > > > > > Karim Fodil-Lemelin wrote: > > > Hi, > > > > I am jumping in here, was too busy to read the list for the last 2 > > weeks, so please excuse my intrusion. We are using T/TCP in our > > product line and are very happy with the performance gain. Could you > > tell me what is the rational for removing T/TCP > > (security/performances/code complexity, etc ..) from FreeBSD? > > > > Again, sorry for being a bit off topic here. > > > what a pitty you didn't notice while it was under discussion: :-( > > > We couldn't find anyone using it... > > what is your product? > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 21:18:45 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 831BA16A4CE for ; Thu, 4 Nov 2004 21:18:45 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F57543D31 for ; Thu, 4 Nov 2004 21:18:45 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id iA4LJKR4019628; Thu, 4 Nov 2004 13:19:20 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id iA4LJKnO019627; Thu, 4 Nov 2004 13:19:20 -0800 Date: Thu, 4 Nov 2004 13:19:20 -0800 From: Brooks Davis To: Alain Dazzi Message-ID: <20041104211920.GC28789@odin.ac.hmc.edu> References: <085485A8ADCB4B49874A54D6185A21FD618834@exch2.verniernetworks.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Sr1nOIr3CvdE5hEN" Content-Disposition: inline In-Reply-To: <085485A8ADCB4B49874A54D6185A21FD618834@exch2.verniernetworks.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-arch@freebsd.org Subject: Re: VIA c3 support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 21:18:45 -0000 --Sr1nOIr3CvdE5hEN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 03, 2004 at 11:00:01AM -0800, Alain Dazzi wrote: > Does FreeBSD 5.3 support the VIA C3 processor? Yes. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --Sr1nOIr3CvdE5hEN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBipzYXY6L6fI4GtQRAiCSAKCUBSGUXEf8wHRk6ljBkqFeYCmhwQCfdYFi 6ASF7NPnFnsfpd6WBZ1m0xM= =0U8w -----END PGP SIGNATURE----- --Sr1nOIr3CvdE5hEN-- From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 22:47:21 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45E3E16A4CE for ; Thu, 4 Nov 2004 22:47:21 +0000 (GMT) Received: from freebee.digiware.nl (dsl439.iae.nl [212.61.63.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id E128843D55 for ; Thu, 4 Nov 2004 22:47:19 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual.digiware.nl [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id iA4MlI5p096680 for ; Thu, 4 Nov 2004 23:47:18 +0100 (CET) (envelope-from wjw@withagen.nl) Message-ID: <418AB176.9030604@withagen.nl> Date: Thu, 04 Nov 2004 23:47:18 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "arch@freebsd.org" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 22:47:21 -0000 Hi, I'm looking for a place to sensibly insert memorytest routines.... Currently I'd like to do that not in the loader, but in the kernel where memory is already setup to be one flat address space. This makes programming a lot simpler. A sensible place, from what I can deduct, would be before the vm_ksubmap_init in the chunck from machdep.c: ---- /* * Display any holes after the first chunk of extended memory. */ if (bootverbose) { int indx; printf("Physical memory chunk(s):\n"); for (indx = 0; phys_avail[indx + 1] != 0; indx += 2) { vm_paddr_t size; size = phys_avail[indx + 1] - phys_avail[indx]; printf( "0x%016jx - 0x%016jx, %ju bytes (%ju pages)\n", (uintmax_t)phys_avail[indx], (uintmax_t)phys_avail[indx + 1] - 1, (uintmax_t)size, (uintmax_t)size / PAGE_SIZE); } } #ifdef MEMTEST if (bootmemtest) { for (indx = 0; phys_avail[indx + 1] != 0; indx += 2) { vm_paddr_t size; size = phys_avail[indx + 1] - phys_avail[indx]; memtest ( /* start */ (uintmax_t)phys_avail[indx], /* end */ (uintmax_t)phys_avail[indx + 1] - 1, /*size */ (uintmax_t)size ); } } #endif MEMTEST vm_ksubmap_init(&kmi); ---- And in memtest I can just linearly iterate over the memory between these pointers without getting pagefaults.... Next question is where to watch for already taken memory: - code - data - stack What modules are already setup by the time we enter the code above??? Or the alternative would be to just exclude for the code and data of the memtests routines them selves. But then printf would probably be destroyed as well, and there would be no "tracing" of memtest activity. Thanx, --WjW From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 22:56:32 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57A3716A4CE for ; Thu, 4 Nov 2004 22:56:32 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4535543D1D for ; Thu, 4 Nov 2004 22:56:32 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 214E07A41E; Thu, 4 Nov 2004 14:56:32 -0800 (PST) Message-ID: <418AB39F.10803@elischer.org> Date: Thu, 04 Nov 2004 14:56:31 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Willem Jan Withagen References: <418AB176.9030604@withagen.nl> In-Reply-To: <418AB176.9030604@withagen.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "arch@freebsd.org" Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 22:56:32 -0000 Willem Jan Withagen wrote: > Hi, > > I'm looking for a place to sensibly insert memorytest routines.... > > Currently I'd like to do that not in the loader, but in the kernel > where memory is already setup to be one flat address space. This makes > programming a lot simpler. I'd argue that it should just be a program that can be loadd by the loader and executed. memtest86 could just be loaded and run. From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 23:06:48 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FC0516A4CE for ; Thu, 4 Nov 2004 23:06:48 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDED843D1F for ; Thu, 4 Nov 2004 23:06:47 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iA4N8iQm028383; Thu, 4 Nov 2004 16:08:45 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <418AB649.80809@freebsd.org> Date: Thu, 04 Nov 2004 16:07:53 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Willem Jan Withagen References: <418AB176.9030604@withagen.nl> In-Reply-To: <418AB176.9030604@withagen.nl> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: "arch@freebsd.org" Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 23:06:48 -0000 Willem Jan Withagen wrote: > Hi, > > I'm looking for a place to sensibly insert memorytest routines.... > > Currently I'd like to do that not in the loader, but in the kernel where > memory is already setup to be one flat address space. This makes > programming a lot simpler. > > A sensible place, from what I can deduct, would be before the > vm_ksubmap_init in the chunck from machdep.c: > ---- > /* > * Display any holes after the first chunk of extended memory. > */ > if (bootverbose) { > int indx; > > printf("Physical memory chunk(s):\n"); > for (indx = 0; phys_avail[indx + 1] != 0; indx += 2) { > vm_paddr_t size; > > size = phys_avail[indx + 1] - phys_avail[indx]; > printf( > "0x%016jx - 0x%016jx, %ju bytes (%ju pages)\n", > (uintmax_t)phys_avail[indx], > (uintmax_t)phys_avail[indx + 1] - 1, > (uintmax_t)size, (uintmax_t)size / PAGE_SIZE); > } > } > #ifdef MEMTEST > if (bootmemtest) { > for (indx = 0; phys_avail[indx + 1] != 0; indx += 2) { > vm_paddr_t size; > > size = phys_avail[indx + 1] - phys_avail[indx]; > memtest ( > /* start */ (uintmax_t)phys_avail[indx], > /* end */ (uintmax_t)phys_avail[indx + 1] > - 1, > /*size */ (uintmax_t)size > ); > } > } > #endif MEMTEST > vm_ksubmap_init(&kmi); > ---- > > And in memtest I can just linearly iterate over the memory between these > pointers without getting pagefaults.... > > Next question is where to watch for already taken memory: > - code > - data > - stack > What modules are already setup by the time we enter the code above??? > > Or the alternative would be to just exclude for the code and data of the > memtests routines them selves. But then printf would probably be > destroyed as well, and there would be no "tracing" of memtest activity. > > Thanx, > --WjW > The loader has a protected mode environment. It is apparently not all that hard to port memtest86 into it. I'd highly recommend doing this rather than trying to hack up the early pmap initialization. Scott From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 23:08:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8B0716A4CE for ; Thu, 4 Nov 2004 23:08:14 +0000 (GMT) Received: from freebee.digiware.nl (dsl439.iae.nl [212.61.63.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 014F943D41 for ; Thu, 4 Nov 2004 23:08:14 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual.digiware.nl [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id iA4N875p006024; Fri, 5 Nov 2004 00:08:08 +0100 (CET) (envelope-from wjw@withagen.nl) Message-ID: <418AB658.9060302@withagen.nl> Date: Fri, 05 Nov 2004 00:08:08 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <418AB176.9030604@withagen.nl> <418AB39F.10803@elischer.org> In-Reply-To: <418AB39F.10803@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "arch@freebsd.org" Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 23:08:14 -0000 Julian Elischer wrote: >> I'm looking for a place to sensibly insert memorytest routines.... >> >> Currently I'd like to do that not in the loader, but in the kernel >> where memory is already setup to be one flat address space. This makes >> programming a lot simpler. > > > > I'd argue that it should just be a program that can be loadd by the > loader and executed. > > memtest86 could just be loaded and run. Fair argument, and something that I've been contemplating as well. However, this is complicated by the fact that there are several architectures that then need to be addressed in their native mode with all the platform quirks. Memtest86 is not for the faint of heart to look at. The routines are straight forward, but getting it there and run them is not so easy. And show obvious why it is rather x86 specific. That's why it is really a seperate entity. Getting it to boot is clumsy, you need to put it on a floppy or CD and (re)boot. The next step would be to "imitate" a kernel booting to the point where I got and do the memory test. This then would be the seperate module/program to load. And you can do: unload load memtest boot -m 6 /* or something like this */ And get the first 6 tests on run your memory. Whether the other modules of the kernel are there or not is rather not essential then. After completing the tests we "reboot". I would need some of the kernel, but as little as possible to get to 1 working processor, the flat memory addressspace and at least printf working. The advantage of this aproach is that it is (more) architecture independant, unless routines are again written in ASM for speed. But that I consider a second stage optimisation. --WjW From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 23:17:30 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E01B16A4CF; Thu, 4 Nov 2004 23:17:30 +0000 (GMT) Received: from freebee.digiware.nl (dsl439.iae.nl [212.61.63.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 834A343D2F; Thu, 4 Nov 2004 23:17:29 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual.digiware.nl [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id iA4NHS5p006393; Fri, 5 Nov 2004 00:17:28 +0100 (CET) (envelope-from wjw@withagen.nl) Message-ID: <418AB888.7070305@withagen.nl> Date: Fri, 05 Nov 2004 00:17:28 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <418AB176.9030604@withagen.nl> <418AB649.80809@freebsd.org> In-Reply-To: <418AB649.80809@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "arch@freebsd.org" Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 23:17:30 -0000 Scott Long wrote: > The loader has a protected mode environment. It is apparently not all > that hard to port memtest86 into it. I'd highly recommend doing this > rather than trying to hack up the early pmap initialization. Is that so.... I was unable to find that. :( can you give me a pointer?? And like I wrote in the previous discussion. The algorithms are not all that difficult to write. It is getting easy access to the memory. If you look at memtest86, you'll that they have to get a lot of work done to get to the actual job: memory testing. And that only for the x86 type processors, which are already served by memtest86. But reading your question, the answer would be: too complex to get this figured out Then how about this: what minimal parts of the kernel do I need to get at least: 1 cpu booted flat memoryspace printf working on the console (vga of serial) areas which are taken by the above. do I again get into pmap init stuff. --WjW From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 23:22:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80F1F16A4CE for ; Thu, 4 Nov 2004 23:22:08 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 194AF43D54 for ; Thu, 4 Nov 2004 23:22:08 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iA4NO5hX028452; Thu, 4 Nov 2004 16:24:05 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <418AB9E2.6070708@freebsd.org> Date: Thu, 04 Nov 2004 16:23:14 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Willem Jan Withagen References: <418AB176.9030604@withagen.nl> <418AB649.80809@freebsd.org> <418AB888.7070305@withagen.nl> In-Reply-To: <418AB888.7070305@withagen.nl> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: "arch@freebsd.org" Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 23:22:08 -0000 Willem Jan Withagen wrote: > Scott Long wrote: > >> The loader has a protected mode environment. It is apparently not all >> that hard to port memtest86 into it. I'd highly recommend doing this >> rather than trying to hack up the early pmap initialization. > > > Is that so.... I was unable to find that. :( can you give me a pointer?? Sorry, I know of some private efforts, but not any public efforts. > > And like I wrote in the previous discussion. The algorithms are not all > that difficult to write. It is getting easy access to the memory. > If you look at memtest86, you'll that they have to get a lot of work > done to get to the actual job: memory testing. > And that only for the x86 type processors, which are already served by > memtest86. > > But reading your question, the answer would be: > too complex to get this figured out Not too complex, just full of landmines. I'm not sure that you can put generic code into the VM system to do this without concerning yourself about the per-arch pmap layout. Also, how do you handle traps that are generated by the memtest? That's another per-arch thing that you have to think about. Scott From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 23:24:55 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D47D516A4CE; Thu, 4 Nov 2004 23:24:55 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B384B43D66; Thu, 4 Nov 2004 23:24:55 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 7B78A7A439; Thu, 4 Nov 2004 15:24:55 -0800 (PST) Message-ID: <418ABA47.7080306@elischer.org> Date: Thu, 04 Nov 2004 15:24:55 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Willem Jan Withagen References: <418AB176.9030604@withagen.nl> <418AB649.80809@freebsd.org> <418AB888.7070305@withagen.nl> In-Reply-To: <418AB888.7070305@withagen.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: "arch@freebsd.org" cc: Scott Long Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 23:24:56 -0000 Willem Jan Withagen wrote: > Scott Long wrote: > >> The loader has a protected mode environment. It is apparently not all >> that hard to port memtest86 into it. I'd highly recommend doing this >> rather than trying to hack up the early pmap initialization. > > > Is that so.... I was unable to find that. :( can you give me a pointer?? > > And like I wrote in the previous discussion. The algorithms are not > all that difficult to write. It is getting easy access to the memory. > If you look at memtest86, you'll that they have to get a lot of work > done to get to the actual job: memory testing. > And that only for the x86 type processors, which are already served by > memtest86. > > But reading your question, the answer would be: > too complex to get this figured out > > Then how about this: > what minimal parts of the kernel do I need to get at least: > 1 cpu booted > flat memoryspace > printf working on the console (vga of serial) > areas which are taken by the above. > do I again get into pmap init stuff. you can not get all memory in a flat memory space with the advent of PAE. you need to page it in and out of the address space. I THINK the latest memtest86 does this.. I used to have a memory test that was based on the 1st stage bootlblocks (The thing that loads the loader) it was quite easy from that point.. you had full control of the memory and the disk and could load files and beat up anything. > > > --WjW > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 23:41:39 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A1CD16A4CE; Thu, 4 Nov 2004 23:41:39 +0000 (GMT) Received: from freebee.digiware.nl (dsl439.iae.nl [212.61.63.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6499043D31; Thu, 4 Nov 2004 23:41:38 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual.digiware.nl [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id iA4Nfa5p007236; Fri, 5 Nov 2004 00:41:37 +0100 (CET) (envelope-from wjw@withagen.nl) Message-ID: <418ABE31.9040502@withagen.nl> Date: Fri, 05 Nov 2004 00:41:37 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <418AB176.9030604@withagen.nl> <418AB649.80809@freebsd.org> <418AB888.7070305@withagen.nl> <418AB9E2.6070708@freebsd.org> In-Reply-To: <418AB9E2.6070708@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "arch@freebsd.org" Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 23:41:39 -0000 Scott Long wrote: >>> The loader has a protected mode environment. It is apparently not all >>> that hard to port memtest86 into it. I'd highly recommend doing this >>> rather than trying to hack up the early pmap initialization. >> >> Is that so.... I was unable to find that. :( can you give me a pointer?? > > Sorry, I know of some private efforts, but not any public efforts. To bad... Would be nice, but perhaps again too much arch dependant. >> And like I wrote in the previous discussion. The algorithms are not >> all that difficult to write. It is getting easy access to the memory. >> If you look at memtest86, you'll that they have to get a lot of work >> done to get to the actual job: memory testing. >> And that only for the x86 type processors, which are already served by >> memtest86. >> >> But reading your question, the answer would be: >> too complex to get this figured out > > Not too complex, just full of landmines. I'm not sure that you can put > generic code into the VM system to do this without concerning yourself > about the per-arch pmap layout. Also, how do you handle traps that are > generated by the memtest? That's another per-arch thing that you have > to think about. That's why I was looking at the phys_avail[] ranges, assuming that the kernel has a relative simple mapping (1:1) on this. Perhaps a little naive, but I'm not really aware of any runtime traps that can occur whilest staying within the ranges of valid memory. Not counting NMI's when parity errors occur. Not shure what ECC-memory would give me if the errors prove to be uncorrectable. e.g. Illegal instruction traps should not occur, since this would be either a compiler error or programmer error. (not shure that memtest86 does anything serious with traps....) Julian made a valid point, which I had not thought of: PAE. That is again back to 1980, and do bankswapping to get > 64KB on a Z80 :) --WjW From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 23:41:53 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0ABA916A4CE for ; Thu, 4 Nov 2004 23:41:53 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC23643D46 for ; Thu, 4 Nov 2004 23:41:52 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 5459 invoked from network); 4 Nov 2004 23:41:52 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 4 Nov 2004 23:41:52 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iA4Nffsd089534; Thu, 4 Nov 2004 18:41:42 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Thu, 4 Nov 2004 18:35:46 -0500 User-Agent: KMail/1.6.2 References: <418AB176.9030604@withagen.nl> In-Reply-To: <418AB176.9030604@withagen.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411041835.46465.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: "arch@freebsd.org" cc: Willem Jan Withagen Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 23:41:53 -0000 On Thursday 04 November 2004 05:47 pm, Willem Jan Withagen wrote: > Hi, > > I'm looking for a place to sensibly insert memorytest routines.... > > Currently I'd like to do that not in the loader, but in the kernel where > memory is already setup to be one flat address space. This makes > programming a lot simpler. The loader does use a flat address space, it is just rooted at 0xa000 rather than 0x0, so you can't test the first few kb FWIW. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 23:41:53 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BB2F16A4CF for ; Thu, 4 Nov 2004 23:41:53 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE3EA43D49 for ; Thu, 4 Nov 2004 23:41:52 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 5459 invoked from network); 4 Nov 2004 23:41:52 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 4 Nov 2004 23:41:52 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iA4Nffsd089534; Thu, 4 Nov 2004 18:41:42 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Thu, 4 Nov 2004 18:35:46 -0500 User-Agent: KMail/1.6.2 References: <418AB176.9030604@withagen.nl> In-Reply-To: <418AB176.9030604@withagen.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411041835.46465.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: "arch@freebsd.org" cc: Willem Jan Withagen Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 23:41:53 -0000 On Thursday 04 November 2004 05:47 pm, Willem Jan Withagen wrote: > Hi, > > I'm looking for a place to sensibly insert memorytest routines.... > > Currently I'd like to do that not in the loader, but in the kernel where > memory is already setup to be one flat address space. This makes > programming a lot simpler. The loader does use a flat address space, it is just rooted at 0xa000 rather than 0x0, so you can't test the first few kb FWIW. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 23:55:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01CD916A4CE; Thu, 4 Nov 2004 23:55:00 +0000 (GMT) Received: from freebee.digiware.nl (dsl439.iae.nl [212.61.63.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id D75D343D5D; Thu, 4 Nov 2004 23:54:58 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual.digiware.nl [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id iA4Nss5p013662; Fri, 5 Nov 2004 00:54:54 +0100 (CET) (envelope-from wjw@withagen.nl) Message-ID: <418AC14E.4040005@withagen.nl> Date: Fri, 05 Nov 2004 00:54:54 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <418AB176.9030604@withagen.nl> <418AB649.80809@freebsd.org> <418AB888.7070305@withagen.nl> <418ABA47.7080306@elischer.org> In-Reply-To: <418ABA47.7080306@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "arch@freebsd.org" cc: Scott Long Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 23:55:00 -0000 Julian Elischer wrote: > > > Willem Jan Withagen wrote: > >> Scott Long wrote: >> >>> The loader has a protected mode environment. It is apparently not all >>> that hard to port memtest86 into it. I'd highly recommend doing this >>> rather than trying to hack up the early pmap initialization. >> >> >> >> Is that so.... I was unable to find that. :( can you give me a pointer?? >> >> And like I wrote in the previous discussion. The algorithms are not >> all that difficult to write. It is getting easy access to the memory. >> If you look at memtest86, you'll that they have to get a lot of work >> done to get to the actual job: memory testing. >> And that only for the x86 type processors, which are already served by >> memtest86. >> >> But reading your question, the answer would be: >> too complex to get this figured out >> >> Then how about this: >> what minimal parts of the kernel do I need to get at least: >> 1 cpu booted >> flat memoryspace >> printf working on the console (vga of serial) >> areas which are taken by the above. >> do I again get into pmap init stuff. > > > > > you can not get all memory in a flat memory space with the advent of PAE. > you need to page it in and out of the address space. > I THINK the latest memtest86 does this.. I got lost in all the code spins in memtest86... Ant thinking that there would be a simpler aproach, I stopped trying to understand all. > I used to have a memory test that was based on the 1st stage bootlblocks > (The thing that loads the loader) > it was quite easy from that point.. > you had full control of the memory and the disk and could load files and > beat up anything. Eeek, boot1 is ASM, and boot2 is fully loaded with v86 on i386.... And now I come to think of it, it would not really work for me, since I'm using GRUB to actually get directly to /boot/loader. But that's rather specific in my case. --WjW From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 23:57:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FC2016A4CE; Thu, 4 Nov 2004 23:57:14 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5077743D4C; Thu, 4 Nov 2004 23:57:14 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) iA4NvBvA024365; Thu, 4 Nov 2004 15:57:11 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id iA4NvAkY024364; Thu, 4 Nov 2004 15:57:10 -0800 (PST) (envelope-from dillon) Date: Thu, 4 Nov 2004 15:57:10 -0800 (PST) From: Matthew Dillon Message-Id: <200411042357.iA4NvAkY024364@apollo.backplane.com> To: John Baldwin References: <48555.1099585930@critter.freebsd.dk> <418A5A72.6020700@freebsd.org> <200411041456.33778.jhb@FreeBSD.org> cc: arch@freebsd.org cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: Poul-Henning Kamp cc: Scott Long cc: freebsd-arch@freebsd.org Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 23:57:14 -0000 :Identical to x86 for now. Note that it would be really nice at some point to :drive hardclock and statclock via the local APIC timers for SMP on x86 and :amd64 so we can stop sending IPIs for each clock interrupt. Alpha uses the :per-CPU timers this way already. : :-- :John Baldwin <>< http://www.FreeBSD.org/~jhb/ I'd recommend taking a look at the DragonFly SYSTIMER API which is basically exactly what you need here. It has a simple API for registration and management of any number of one-shot and periodic timer events, with interrupt callback (the frame is available), per-cpu distribution, and so forth. Right now we are driving the backend off a single timer but the API is designed with the future use of per-cpu LAPIC timers in mind. The SYSTIMER module will also aggregate events that happen to occur at the same time. It's a very nice abstraction and you could probably even port it over without also having to port our IPI messaging (though I would strongly recommend you do that too). You could even adapt it to be based off a fixed HZ timer, it just means it will aggregate more events, though my original purpose for writing it was to make a fine-grained abstraction available to the system. All of our clock distribution is based on separately registered systimers now instead of being integrated into one big huge mess like it is in the BSD's (which in turn was inherited from CSRG and hacked to pieces ever since). Interfacing the systimer module to a machine-dependant clock interrupt ought to be fairly trivial. It's only 218 lines, *inclusive* of the DFly copyright. http://www.dragonflybsd.org/cgi-bin/cvsweb.cgi/src/sys/kern/kern_systimer.c http://www.dragonflybsd.org/cgi-bin/cvsweb.cgi/src/sys/sys/systimer.h -Matt Matthew Dillon From owner-freebsd-arch@FreeBSD.ORG Thu Nov 4 23:57:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FC2016A4CE; Thu, 4 Nov 2004 23:57:14 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5077743D4C; Thu, 4 Nov 2004 23:57:14 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) iA4NvBvA024365; Thu, 4 Nov 2004 15:57:11 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id iA4NvAkY024364; Thu, 4 Nov 2004 15:57:10 -0800 (PST) (envelope-from dillon) Date: Thu, 4 Nov 2004 15:57:10 -0800 (PST) From: Matthew Dillon Message-Id: <200411042357.iA4NvAkY024364@apollo.backplane.com> To: John Baldwin References: <48555.1099585930@critter.freebsd.dk> <418A5A72.6020700@freebsd.org> <200411041456.33778.jhb@FreeBSD.org> cc: arch@freebsd.org cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: Poul-Henning Kamp cc: Scott Long cc: freebsd-arch@freebsd.org Subject: Re: HEADSUP: HZ=1000 by default on i386 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 23:57:14 -0000 :Identical to x86 for now. Note that it would be really nice at some point to :drive hardclock and statclock via the local APIC timers for SMP on x86 and :amd64 so we can stop sending IPIs for each clock interrupt. Alpha uses the :per-CPU timers this way already. : :-- :John Baldwin <>< http://www.FreeBSD.org/~jhb/ I'd recommend taking a look at the DragonFly SYSTIMER API which is basically exactly what you need here. It has a simple API for registration and management of any number of one-shot and periodic timer events, with interrupt callback (the frame is available), per-cpu distribution, and so forth. Right now we are driving the backend off a single timer but the API is designed with the future use of per-cpu LAPIC timers in mind. The SYSTIMER module will also aggregate events that happen to occur at the same time. It's a very nice abstraction and you could probably even port it over without also having to port our IPI messaging (though I would strongly recommend you do that too). You could even adapt it to be based off a fixed HZ timer, it just means it will aggregate more events, though my original purpose for writing it was to make a fine-grained abstraction available to the system. All of our clock distribution is based on separately registered systimers now instead of being integrated into one big huge mess like it is in the BSD's (which in turn was inherited from CSRG and hacked to pieces ever since). Interfacing the systimer module to a machine-dependant clock interrupt ought to be fairly trivial. It's only 218 lines, *inclusive* of the DFly copyright. http://www.dragonflybsd.org/cgi-bin/cvsweb.cgi/src/sys/kern/kern_systimer.c http://www.dragonflybsd.org/cgi-bin/cvsweb.cgi/src/sys/sys/systimer.h -Matt Matthew Dillon From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 00:09:25 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A154216A4CE; Fri, 5 Nov 2004 00:09:25 +0000 (GMT) Received: from freebee.digiware.nl (dsl439.iae.nl [212.61.63.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB36243D48; Fri, 5 Nov 2004 00:09:24 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual.digiware.nl [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id iA509N5p017724; Fri, 5 Nov 2004 01:09:23 +0100 (CET) (envelope-from wjw@withagen.nl) Message-ID: <418AC4B3.9020305@withagen.nl> Date: Fri, 05 Nov 2004 01:09:23 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <418AB176.9030604@withagen.nl> <200411041835.46465.jhb@FreeBSD.org> In-Reply-To: <200411041835.46465.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "arch@freebsd.org" cc: freebsd-arch@freebsd.org Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 00:09:25 -0000 John Baldwin wrote: > On Thursday 04 November 2004 05:47 pm, Willem Jan Withagen wrote: > >>Hi, >> >>I'm looking for a place to sensibly insert memorytest routines.... >> >>Currently I'd like to do that not in the loader, but in the kernel where >>memory is already setup to be one flat address space. This makes >>programming a lot simpler. > > > The loader does use a flat address space, it is just rooted at 0xa000 rather > than 0x0, so you can't test the first few kb FWIW. Nice, But is it unsegmented? (perhaps I have a wrong idea of a flat address space) What I mean with this is that I can iterate from 0xa000 to 0xffffffff with a "char *p" and do test_bytes( 0xa000, 0xffffffff, 0xff). (assuming this all has memory) test_bytes( char *start, char* end, char mask) { char *save; while (start < end ) { *start = mask; start++; } start = save; while (start < end ) { if (*start != mask) error(start); start++; } } Next is then which ranges are valid to test, and then things really start to get complicated and arch dependant. Which is why I ended up in machdep.c right after the setting up of the memory ranges. --WjW From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 00:09:25 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A154216A4CE; Fri, 5 Nov 2004 00:09:25 +0000 (GMT) Received: from freebee.digiware.nl (dsl439.iae.nl [212.61.63.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB36243D48; Fri, 5 Nov 2004 00:09:24 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual.digiware.nl [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id iA509N5p017724; Fri, 5 Nov 2004 01:09:23 +0100 (CET) (envelope-from wjw@withagen.nl) Message-ID: <418AC4B3.9020305@withagen.nl> Date: Fri, 05 Nov 2004 01:09:23 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <418AB176.9030604@withagen.nl> <200411041835.46465.jhb@FreeBSD.org> In-Reply-To: <200411041835.46465.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "arch@freebsd.org" cc: freebsd-arch@freebsd.org Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 00:09:25 -0000 John Baldwin wrote: > On Thursday 04 November 2004 05:47 pm, Willem Jan Withagen wrote: > >>Hi, >> >>I'm looking for a place to sensibly insert memorytest routines.... >> >>Currently I'd like to do that not in the loader, but in the kernel where >>memory is already setup to be one flat address space. This makes >>programming a lot simpler. > > > The loader does use a flat address space, it is just rooted at 0xa000 rather > than 0x0, so you can't test the first few kb FWIW. Nice, But is it unsegmented? (perhaps I have a wrong idea of a flat address space) What I mean with this is that I can iterate from 0xa000 to 0xffffffff with a "char *p" and do test_bytes( 0xa000, 0xffffffff, 0xff). (assuming this all has memory) test_bytes( char *start, char* end, char mask) { char *save; while (start < end ) { *start = mask; start++; } start = save; while (start < end ) { if (*start != mask) error(start); start++; } } Next is then which ranges are valid to test, and then things really start to get complicated and arch dependant. Which is why I ended up in machdep.c right after the setting up of the memory ranges. --WjW From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 10:26:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF7B016A4CE; Fri, 5 Nov 2004 10:26:01 +0000 (GMT) Received: from freebee.digiware.nl (dsl439.iae.nl [212.61.63.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF1AF43D39; Fri, 5 Nov 2004 10:26:00 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual.digiware.nl [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id iA5APq5p043786; Fri, 5 Nov 2004 11:25:52 +0100 (CET) (envelope-from wjw@withagen.nl) Message-ID: <418B5531.9070507@withagen.nl> Date: Fri, 05 Nov 2004 11:25:53 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Willem Jan Withagen References: <418AB176.9030604@withagen.nl> <418AB649.80809@freebsd.org> <418AB888.7070305@withagen.nl> <418AB9E2.6070708@freebsd.org> <418ABE31.9040502@withagen.nl> In-Reply-To: <418ABE31.9040502@withagen.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "arch@freebsd.org" cc: Scott Long Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 10:26:01 -0000 Willem Jan Withagen wrote: > Scott Long wrote: > >>>> The loader has a protected mode environment. It is apparently not all >>>> that hard to port memtest86 into it. I'd highly recommend doing this >>>> rather than trying to hack up the early pmap initialization. >>> >>> >>> Is that so.... I was unable to find that. :( can you give me a pointer?? >> >> >> Sorry, I know of some private efforts, but not any public efforts. > > To bad... Would be nice, but perhaps again too much arch dependant. I mailed with Guido, who told me he heard people talk about this on EuroBSDcon. So my guess is that it is still somewhere in someones perforce tree... Do you know about any intentions of that person to actually release any of the code?? --WjW From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 15:28:28 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E61D16A4CE; Fri, 5 Nov 2004 15:28:28 +0000 (GMT) Received: from gvr.gvr.org (gvr-gw.gvr.org [80.126.103.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF98343D49; Fri, 5 Nov 2004 15:28:27 +0000 (GMT) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 028D92B; Fri, 5 Nov 2004 16:28:26 +0100 (CET) Date: Fri, 5 Nov 2004 16:28:26 +0100 From: Guido van Rooij To: Willem Jan Withagen Message-ID: <20041105152826.GA27117@gvr.gvr.org> References: <418AB176.9030604@withagen.nl> <418AB649.80809@freebsd.org> <418AB888.7070305@withagen.nl> <418AB9E2.6070708@freebsd.org> <418ABE31.9040502@withagen.nl> <418B5531.9070507@withagen.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <418B5531.9070507@withagen.nl> cc: "arch@freebsd.org" cc: Scott Long Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 15:28:28 -0000 On Fri, Nov 05, 2004 at 11:25:53AM +0100, Willem Jan Withagen wrote: > Willem Jan Withagen wrote: > > >Scott Long wrote: > > > >>>>The loader has a protected mode environment. It is apparently not all > >>>>that hard to port memtest86 into it. I'd highly recommend doing this > >>>>rather than trying to hack up the early pmap initialization. > >>> > >>> > >>>Is that so.... I was unable to find that. :( can you give me a pointer?? > >> > >> > >>Sorry, I know of some private efforts, but not any public efforts. > > > >To bad... Would be nice, but perhaps again too much arch dependant. > > I mailed with Guido, who told me he heard people talk about this on > EuroBSDcon. So my guess is that it is still somewhere in someones perforce > tree... Do you know about any intentions of that person to actually release > any of the code?? Waht I heart was that the loader operated in protected mode and flat address space, but without the MMU active. That should be enough. I am not sure about what "effort" Scott is talking about... -Guido From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 16:08:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9FE316A4CE; Fri, 5 Nov 2004 16:08:43 +0000 (GMT) Received: from mail.net (custpop.ca.mci.com [142.77.1.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 288B543D49; Fri, 5 Nov 2004 16:08:43 +0000 (GMT) (envelope-from kfl@xiphos.ca) Received: from [216.95.199.148] (account kfl@xiphos.ca HELO [192.168.1.7]) by mail.net (CommuniGate Pro SMTP 4.2.5) with ESMTP id 26420170; Fri, 05 Nov 2004 11:08:42 -0500 Message-ID: <418BA8DC.4040101@xiphos.ca> Date: Fri, 05 Nov 2004 11:22:52 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <20041022182430.31A2B1EF3BF@lawyers.icir.org> <418A6FDC.5010204@xiphos.ca> <418A9699.6050603@elischer.org> In-Reply-To: <418A9699.6050603@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org cc: Andre Oppermann cc: mallman@icir.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 16:08:44 -0000 Our product is a TCP/IP accelerator for satellite communications please see http://www.xiplink.com/technology/xiplink_technology-datasheet.html. Also, please see http://www.scps.org/scps/ for an explanation of our Transport layer implementation. BTW, The marketing dep has renamed T/TCP to fast start and we actually made some modifications to FreeBSD's T/TCP but the rfc1644 principles are the same. Julian Elischer wrote: > > > Karim Fodil-Lemelin wrote: > >> Hi, >> >> I am jumping in here, was too busy to read the list for the last 2 >> weeks, so please excuse my intrusion. We are using T/TCP in our >> product line and are very happy with the performance gain. Could you >> tell me what is the rational for removing T/TCP >> (security/performances/code complexity, etc ..) from FreeBSD? >> >> Again, sorry for being a bit off topic here. > > > > what a pitty you didn't notice while it was under discussion: :-( Yes It is although we are very flexible and so a replacement might be as good if not better then what we have now. Especially from a code and security perspective. We have always appreciated BSD Engineering process and I believe that until we get to see FreeBSD 6.x STABLE we will be more then ready. > > > We couldn't find anyone using it... > > what is your product? > > > -- Karim Fodil-Lemelin Lead Programmer Xiphos Technologies Inc. (514) 848-9640 x223 (514) 848-9644 fax www.xiplink.com -------------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you have received this in error, please contact the sender and delete this communication and any copy immediately. Thank you. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 16:39:22 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74F0A16A4CE; Fri, 5 Nov 2004 16:39:22 +0000 (GMT) Received: from mail.net (custpop.ca.mci.com [142.77.1.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id B818543D39; Fri, 5 Nov 2004 16:39:21 +0000 (GMT) (envelope-from kfl@xiphos.ca) Received: from [216.95.199.148] (account kfl@xiphos.ca HELO [192.168.1.7]) by mail.net (CommuniGate Pro SMTP 4.2.5) with ESMTP id 26425345; Fri, 05 Nov 2004 11:39:20 -0500 Message-ID: <418BB008.6040907@xiphos.ca> Date: Fri, 05 Nov 2004 11:53:28 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matt Sealey References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: mallman@icir.org cc: Andre Oppermann cc: Julian Elischer cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 16:39:22 -0000 Now, I have a question. In our application which can be described as: Client ----> (Client Gateway) -------> SATLINK ------> (Server Gateway) -----> Internet We act as the Internet servers (transparent proxies) and therefore T/TCP traffic is only sent over the SATLINK. In the current T/TCP implementation the sender has to send a ccnew option to discover that the server side supports T/TCP. Now we had to modify this so the gateways uses the knowledge that they work together and they don't need to send a ccnew option everytime a client makes a connection to a new server. My question is: In the new implementation does the cookie will be generated per machine or like the tao mecanism will it be based on a src / dst tuple? Regards. Matt Sealey wrote: >His product looks like it's the the product mentioned in the original post by >the original poster; > >http://docs.freebsd.org/cgi/getmsg.cgi?fetch=284774+0+/usr/local/www/db/text/2004/freebsd-net/20041024.freebsd-net > >QUOTE: > >However something like T/TCP is certainly useful and I know of one special >purpose application using it (Web Proxy Server/Client for high-delay Satellite >connections). > >As long as they can live with FreeBSD 5.3 I don't think it causes a problem >whatsoever does it? > > > Right, Actually we are based on FBSD 4.9 and we are planning to port to 5.3 as soon as it gets stable, which could be anytime soon ;). -- Karim Fodil-Lemelin Lead Programmer Xiphos Technologies Inc. (514) 848-9640 x223 (514) 848-9644 fax www.xiplink.com -------------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you have received this in error, please contact the sender and delete this communication and any copy immediately. Thank you. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 16:46:07 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24CBA16A4D7 for ; Fri, 5 Nov 2004 16:46:07 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4580143D60 for ; Fri, 5 Nov 2004 16:46:06 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 7695 invoked from network); 5 Nov 2004 16:42:00 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Nov 2004 16:42:00 -0000 Message-ID: <418BAE54.72E4208F@freebsd.org> Date: Fri, 05 Nov 2004 17:46:12 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Karim Fodil-Lemelin References: <418BB008.6040907@xiphos.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Matt Sealey cc: mallman@icir.org cc: Julian Elischer cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 16:46:07 -0000 Karim Fodil-Lemelin wrote: > > Now, > > I have a question. In our application which can be described as: > > Client ----> (Client Gateway) -------> SATLINK ------> (Server Gateway) > -----> Internet > > We act as the Internet servers (transparent proxies) and therefore T/TCP > traffic is only sent over the SATLINK. In the current T/TCP > implementation the sender has to send a ccnew option to discover that > the server side supports T/TCP. Now we had to modify this so the > gateways uses the knowledge that they work together and they don't need > to send a ccnew option everytime a client makes a connection to a new > server. > > My question is: In the new implementation does the cookie will be > generated per machine or like the tao mecanism will it be based on a src > / dst tuple? The new cookie system will use the src-host/dst-host tuple. The first tcp connection between two hosts (port numbers are irrelevant) is a normal three-way handshake and the cookie is exchanged. From then on it skips over 3WHS on the server if the cookie matches. -- Andre > Regards. > > Matt Sealey wrote: > > >His product looks like it's the the product mentioned in the original post by > >the original poster; > > > >http://docs.freebsd.org/cgi/getmsg.cgi?fetch=284774+0+/usr/local/www/db/text/2004/freebsd-net/20041024.freebsd-net > > > >QUOTE: > > > >However something like T/TCP is certainly useful and I know of one special > >purpose application using it (Web Proxy Server/Client for high-delay Satellite > >connections). > > > >As long as they can live with FreeBSD 5.3 I don't think it causes a problem > >whatsoever does it? > > > > > > > Right, Actually we are based on FBSD 4.9 and we are planning to port to > 5.3 as soon as it gets stable, which could be anytime soon ;). > > -- > Karim Fodil-Lemelin > Lead Programmer > > Xiphos Technologies Inc. > (514) 848-9640 x223 > (514) 848-9644 fax > www.xiplink.com > > -------------------------------------------------------------- > The information transmitted is intended only for the > person or entity to which it is addressed and may contain > confidential and/or privileged material. If you have > received this in error, please contact the sender and delete > this communication and any copy immediately. Thank you. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 17:12:17 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69E6B16A4CE; Fri, 5 Nov 2004 17:12:17 +0000 (GMT) Received: from mail.net (custpop.ca.mci.com [142.77.1.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A75B43D5C; Fri, 5 Nov 2004 17:12:16 +0000 (GMT) (envelope-from kfl@xiphos.ca) Received: from [216.95.199.148] (account kfl@xiphos.ca HELO [192.168.1.7]) by mail.net (CommuniGate Pro SMTP 4.2.5) with ESMTP id 26430096; Fri, 05 Nov 2004 12:12:12 -0500 Message-ID: <418BB7BC.3010305@xiphos.ca> Date: Fri, 05 Nov 2004 12:26:20 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <418BB008.6040907@xiphos.ca> <418BAE54.72E4208F@freebsd.org> In-Reply-To: <418BAE54.72E4208F@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Matt Sealey cc: mallman@icir.org cc: Julian Elischer cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 17:12:17 -0000 In the case where all connections go through the SATLINK and are splitted by proxies, it make sense to use this knowledge and not renegotiate cookies for every connections since we know there is only one path to the internet and that all SATLINK connections will support (T/TCP or whatever name it will have). Do you have any plan to include that knowledge in your design or is it too much of a special case to really care? Andre Oppermann wrote: >Karim Fodil-Lemelin wrote: > > >>Now, >> >> I have a question. In our application which can be described as: >> >>Client ----> (Client Gateway) -------> SATLINK ------> (Server Gateway) >>-----> Internet >> >>We act as the Internet servers (transparent proxies) and therefore T/TCP >>traffic is only sent over the SATLINK. In the current T/TCP >>implementation the sender has to send a ccnew option to discover that >>the server side supports T/TCP. Now we had to modify this so the >>gateways uses the knowledge that they work together and they don't need >>to send a ccnew option everytime a client makes a connection to a new >>server. >> >>My question is: In the new implementation does the cookie will be >>generated per machine or like the tao mecanism will it be based on a src >>/ dst tuple? >> >> > >The new cookie system will use the src-host/dst-host tuple. The first >tcp connection between two hosts (port numbers are irrelevant) is a >normal three-way handshake and the cookie is exchanged. From then on >it skips over 3WHS on the server if the cookie matches. > > > -- Karim Fodil-Lemelin Lead Programmer Xiphos Technologies Inc. (514) 848-9640 x223 (514) 848-9644 fax www.xiplink.com -------------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you have received this in error, please contact the sender and delete this communication and any copy immediately. Thank you. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 17:31:47 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C872216A4CE for ; Fri, 5 Nov 2004 17:31:47 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 027CF43D54 for ; Fri, 5 Nov 2004 17:31:47 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 8018 invoked from network); 5 Nov 2004 17:27:40 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Nov 2004 17:27:40 -0000 Message-ID: <418BB909.501CC9FD@freebsd.org> Date: Fri, 05 Nov 2004 18:31:53 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Karim Fodil-Lemelin References: <418BB008.6040907@xiphos.ca> <418BAE54.72E4208F@freebsd.org> <418BB7BC.3010305@xiphos.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Matt Sealey cc: mallman@icir.org cc: Julian Elischer cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 17:31:47 -0000 Karim Fodil-Lemelin wrote: > > In the case where all connections go through the SATLINK and are > splitted by proxies, it make sense to use this knowledge and not > renegotiate cookies for every connections since we know there is only > one path to the internet and that all SATLINK connections will support > (T/TCP or whatever name it will have). Do you have any plan to include > that knowledge in your design or is it too much of a special case to > really care? It does not renegotiate cookies for every connection. Only the first connection will do that. Re-seeding of the cookies will happen trans- parently. You pay the 3WSH tax only once for the first connection, or the first connection after a longer idle time when the cookie expired. -- Andre > Andre Oppermann wrote: > > >Karim Fodil-Lemelin wrote: > > > > > >>Now, > >> > >> I have a question. In our application which can be described as: > >> > >>Client ----> (Client Gateway) -------> SATLINK ------> (Server Gateway) > >>-----> Internet > >> > >>We act as the Internet servers (transparent proxies) and therefore T/TCP > >>traffic is only sent over the SATLINK. In the current T/TCP > >>implementation the sender has to send a ccnew option to discover that > >>the server side supports T/TCP. Now we had to modify this so the > >>gateways uses the knowledge that they work together and they don't need > >>to send a ccnew option everytime a client makes a connection to a new > >>server. > >> > >>My question is: In the new implementation does the cookie will be > >>generated per machine or like the tao mecanism will it be based on a src > >>/ dst tuple? > >> > >> > > > >The new cookie system will use the src-host/dst-host tuple. The first > >tcp connection between two hosts (port numbers are irrelevant) is a > >normal three-way handshake and the cookie is exchanged. From then on > >it skips over 3WHS on the server if the cookie matches. > > > > > > > > -- > Karim Fodil-Lemelin > Lead Programmer > > Xiphos Technologies Inc. > (514) 848-9640 x223 > (514) 848-9644 fax > www.xiplink.com > > -------------------------------------------------------------- > The information transmitted is intended only for the > person or entity to which it is addressed and may contain > confidential and/or privileged material. If you have > received this in error, please contact the sender and delete > this communication and any copy immediately. Thank you. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 18:12:04 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C740516A4CE for ; Fri, 5 Nov 2004 18:12:04 +0000 (GMT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE02B43D1F for ; Fri, 5 Nov 2004 18:12:03 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.9p2/8.12.9) with ESMTP id iA5IC2Up090032 for ; Fri, 5 Nov 2004 21:12:02 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.9p2/8.12.9/Submit) id iA5IC16M090030 for arch@freebsd.org; Fri, 5 Nov 2004 21:12:01 +0300 (MSK) (envelope-from yar) Date: Fri, 5 Nov 2004 21:12:01 +0300 From: Yar Tikhiy To: arch@freebsd.org Message-ID: <20041105181201.GA88657@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: Fixes for tar(5) format handling in pax(1) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 18:12:04 -0000 Hi folks, I was pointed out by one of us at PR bin/40466, which described a bug in pax(1) related to handling pathnames of the maximum length specified by tar(5). A quick look at src/bin/pax/tar.c revealed more off-by-one errors and potential buffer overruns in this area. Many of them come from the fact that ustar allows pathnames (name, prefix, linkname) to be unterminated if they fill the entire field while old tar doesn't. Finally I made a patch that should address all of the issues found. Since we have pax in /bin, I'd appreciate if anybody reviewed my patch. Thanks. -- Yar Index: tar.c =================================================================== RCS file: /home/ncvs/src/bin/pax/tar.c,v retrieving revision 1.23 diff -u -p -r1.23 tar.c --- tar.c 6 Apr 2004 20:06:48 -0000 1.23 +++ tar.c 5 Nov 2004 17:44:08 -0000 @@ -387,7 +387,13 @@ tar_rd(ARCHD *arcn, char *buf) * copy out the name and values in the stat buffer */ hd = (HD_TAR *)buf; - arcn->nlen = l_strncpy(arcn->name, hd->name, sizeof(arcn->name) - 1); + /* + * old tar format specifies the name always be null-terminated, + * but let's be robust to broken archives. + * the same applies to handling links below. + */ + arcn->nlen = l_strncpy(arcn->name, hd->name, + MIN(sizeof(hd->name), sizeof(arcn->name)) - 1); arcn->name[arcn->nlen] = '\0'; arcn->sb.st_mode = (mode_t)(asc_ul(hd->mode,sizeof(hd->mode),OCT) & 0xfff); @@ -417,7 +423,7 @@ tar_rd(ARCHD *arcn, char *buf) */ arcn->type = PAX_SLK; arcn->ln_nlen = l_strncpy(arcn->ln_name, hd->linkname, - sizeof(arcn->ln_name) - 1); + MIN(sizeof(hd->linkname), sizeof(arcn->ln_name)) - 1); arcn->ln_name[arcn->ln_nlen] = '\0'; arcn->sb.st_mode |= S_IFLNK; break; @@ -429,7 +435,7 @@ tar_rd(ARCHD *arcn, char *buf) arcn->type = PAX_HLK; arcn->sb.st_nlink = 2; arcn->ln_nlen = l_strncpy(arcn->ln_name, hd->linkname, - sizeof(arcn->ln_name) - 1); + MIN(sizeof(hd->linkname), sizeof(arcn->ln_name)) - 1); arcn->ln_name[arcn->ln_nlen] = '\0'; /* @@ -533,7 +539,7 @@ tar_wr(ARCHD *arcn) case PAX_SLK: case PAX_HLK: case PAX_HRG: - if (arcn->ln_nlen > (int)sizeof(hd->linkname)) { + if (arcn->ln_nlen >= (int)sizeof(hd->linkname)) { paxwarn(1,"Link name too long for tar %s", arcn->ln_name); return(1); } @@ -749,12 +755,19 @@ ustar_rd(ARCHD *arcn, char *buf) */ dest = arcn->name; if (*(hd->prefix) != '\0') { - cnt = l_strncpy(dest, hd->prefix, sizeof(arcn->name) - 2); + cnt = l_strncpy(dest, hd->prefix, + MIN(sizeof(hd->prefix), sizeof(arcn->name) - 2)); dest += cnt; *dest++ = '/'; cnt++; } - arcn->nlen = cnt + l_strncpy(dest, hd->name, sizeof(arcn->name) - cnt); + /* + * ustar format specifies the name may be unterminated + * if it fills the entire field. this also applies to + * the prefix and the linkname. + */ + arcn->nlen = cnt + l_strncpy(dest, hd->name, + MIN(sizeof(hd->name), sizeof(arcn->name) - cnt - 1)); arcn->name[arcn->nlen] = '\0'; /* @@ -848,7 +861,7 @@ ustar_rd(ARCHD *arcn, char *buf) * copy the link name */ arcn->ln_nlen = l_strncpy(arcn->ln_name, hd->linkname, - sizeof(arcn->ln_name) - 1); + MIN(sizeof(hd->linkname), sizeof(arcn->ln_name) - 1)); arcn->ln_name[arcn->ln_nlen] = '\0'; break; case CONTTYPE: @@ -900,7 +913,7 @@ ustar_wr(ARCHD *arcn) */ if (((arcn->type == PAX_SLK) || (arcn->type == PAX_HLK) || (arcn->type == PAX_HRG)) && - (arcn->ln_nlen >= (int)sizeof(hd->linkname))) { + (arcn->ln_nlen > (int)sizeof(hd->linkname))) { paxwarn(1, "Link name too long for ustar %s", arcn->ln_name); return(1); } @@ -925,17 +938,16 @@ ustar_wr(ARCHD *arcn) * occur, we remove the / and copy the first part to the prefix */ *pt = '\0'; - l_strncpy(hd->prefix, arcn->name, sizeof(hd->prefix) - 1); + l_strncpy(hd->prefix, arcn->name, sizeof(hd->prefix)); *pt++ = '/'; } else memset(hd->prefix, 0, sizeof(hd->prefix)); /* * copy the name part. this may be the whole path or the part after - * the prefix + * the prefix. both the name and prefix may fill the entire field. */ - l_strncpy(hd->name, pt, sizeof(hd->name) - 1); - hd->name[sizeof(hd->name) - 1] = '\0'; + l_strncpy(hd->name, pt, sizeof(hd->name)); /* * set the fields in the header that are type dependent @@ -978,8 +990,8 @@ ustar_wr(ARCHD *arcn) hd->typeflag = SYMTYPE; else hd->typeflag = LNKTYPE; - l_strncpy(hd->linkname,arcn->ln_name, sizeof(hd->linkname) - 1); - hd->linkname[sizeof(hd->linkname) - 1] = '\0'; + /* the link name may occupy the entire field in ustar */ + l_strncpy(hd->linkname,arcn->ln_name, sizeof(hd->linkname)); memset(hd->devmajor, 0, sizeof(hd->devmajor)); memset(hd->devminor, 0, sizeof(hd->devminor)); if (ul_oct((u_long)0L, hd->size, sizeof(hd->size), 3)) @@ -1072,9 +1084,9 @@ name_split(char *name, int len) * check to see if the file name is small enough to fit in the name * field. if so just return a pointer to the name. */ - if (len < TNMSZ) + if (len <= TNMSZ) return(name); - if (len > (TPFSZ + TNMSZ)) + if (len > (TPFSZ + TNMSZ + 1)) return(NULL); /* @@ -1083,7 +1095,7 @@ name_split(char *name, int len) * to find the biggest piece to fit in the name field (or the smallest * prefix we can find) */ - start = name + len - TNMSZ; + start = name + len - TNMSZ - 1; while ((*start != '\0') && (*start != '/')) ++start; @@ -1101,7 +1113,7 @@ name_split(char *name, int len) * the file would then expand on extract to //str. The len == 0 below * makes this special case follow the spec to the letter. */ - if ((len >= TPFSZ) || (len == 0)) + if ((len > TPFSZ) || (len == 0)) return(NULL); /* From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 19:05:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99B5A16A4CE for ; Fri, 5 Nov 2004 19:05:00 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EA3243D3F for ; Fri, 5 Nov 2004 19:05:00 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 5926 invoked from network); 5 Nov 2004 19:05:00 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 5 Nov 2004 19:04:59 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iA5J4oJo096288; Fri, 5 Nov 2004 14:04:56 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Willem Jan Withagen Date: Fri, 5 Nov 2004 14:00:34 -0500 User-Agent: KMail/1.6.2 References: <418AB176.9030604@withagen.nl> <200411041835.46465.jhb@FreeBSD.org> <418AC4B3.9020305@withagen.nl> In-Reply-To: <418AC4B3.9020305@withagen.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411051400.34684.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: "arch@freebsd.org" cc: freebsd-arch@FreeBSD.org Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 19:05:00 -0000 On Thursday 04 November 2004 07:09 pm, Willem Jan Withagen wrote: > John Baldwin wrote: > > On Thursday 04 November 2004 05:47 pm, Willem Jan Withagen wrote: > >>Hi, > >> > >>I'm looking for a place to sensibly insert memorytest routines.... > >> > >>Currently I'd like to do that not in the loader, but in the kernel where > >>memory is already setup to be one flat address space. This makes > >>programming a lot simpler. > > > > The loader does use a flat address space, it is just rooted at 0xa000 > > rather than 0x0, so you can't test the first few kb FWIW. > > Nice, > > But is it unsegmented? (perhaps I have a wrong idea of a flat address > space) Yes, it is unsegmented. You can translate physical addresses to virtual addresses using PTOV() and vice versa using VTOP(). > What I mean with this is that I can iterate from 0xa000 to 0xffffffff with > a "char *p" and do test_bytes( 0xa000, 0xffffffff, 0xff). (assuming this > all has memory) Yes. > Next is then which ranges are valid to test, and then things really start > to get complicated and arch dependant. Which is why I ended up in machdep.c > right after the setting up of the memory ranges. Heh, the above memory mapping is also i386 specific. Alpha only has a small bit of memory mapped in the loader, same with sparc64, etc. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 19:05:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3BF216A4CE for ; Fri, 5 Nov 2004 19:05:00 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD7CE43D3F for ; Fri, 5 Nov 2004 19:05:00 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 5926 invoked from network); 5 Nov 2004 19:05:00 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 5 Nov 2004 19:04:59 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iA5J4oJo096288; Fri, 5 Nov 2004 14:04:56 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Willem Jan Withagen Date: Fri, 5 Nov 2004 14:00:34 -0500 User-Agent: KMail/1.6.2 References: <418AB176.9030604@withagen.nl> <200411041835.46465.jhb@FreeBSD.org> <418AC4B3.9020305@withagen.nl> In-Reply-To: <418AC4B3.9020305@withagen.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411051400.34684.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: "arch@freebsd.org" cc: freebsd-arch@FreeBSD.org Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 19:05:01 -0000 On Thursday 04 November 2004 07:09 pm, Willem Jan Withagen wrote: > John Baldwin wrote: > > On Thursday 04 November 2004 05:47 pm, Willem Jan Withagen wrote: > >>Hi, > >> > >>I'm looking for a place to sensibly insert memorytest routines.... > >> > >>Currently I'd like to do that not in the loader, but in the kernel where > >>memory is already setup to be one flat address space. This makes > >>programming a lot simpler. > > > > The loader does use a flat address space, it is just rooted at 0xa000 > > rather than 0x0, so you can't test the first few kb FWIW. > > Nice, > > But is it unsegmented? (perhaps I have a wrong idea of a flat address > space) Yes, it is unsegmented. You can translate physical addresses to virtual addresses using PTOV() and vice versa using VTOP(). > What I mean with this is that I can iterate from 0xa000 to 0xffffffff with > a "char *p" and do test_bytes( 0xa000, 0xffffffff, 0xff). (assuming this > all has memory) Yes. > Next is then which ranges are valid to test, and then things really start > to get complicated and arch dependant. Which is why I ended up in machdep.c > right after the setting up of the memory ranges. Heh, the above memory mapping is also i386 specific. Alpha only has a small bit of memory mapped in the loader, same with sparc64, etc. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 20:34:28 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D61DB16A4CE; Fri, 5 Nov 2004 20:34:28 +0000 (GMT) Received: from freebee.digiware.nl (dsl439.iae.nl [212.61.63.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5D1943D2F; Fri, 5 Nov 2004 20:34:27 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual.digiware.nl [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id iA5KYP5p070451; Fri, 5 Nov 2004 21:34:26 +0100 (CET) (envelope-from wjw@withagen.nl) Message-ID: <418BE3D2.2030205@withagen.nl> Date: Fri, 05 Nov 2004 21:34:26 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <418AB176.9030604@withagen.nl> <200411041835.46465.jhb@FreeBSD.org> <418AC4B3.9020305@withagen.nl> <200411051400.34684.jhb@FreeBSD.org> In-Reply-To: <200411051400.34684.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: Booting questions .... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 20:34:28 -0000 John Baldwin wrote: [about the loader having flat addressspace....] >>But is it unsegmented? (perhaps I have a wrong idea of a flat address >>space) > > > Yes, it is unsegmented. You can translate physical addresses to virtual > addresses using PTOV() and vice versa using VTOP(). I've run accross these calls, just need to figure out how to work them. >>What I mean with this is that I can iterate from 0xa000 to 0xffffffff with >>a "char *p" and do test_bytes( 0xa000, 0xffffffff, 0xff). (assuming this >>all has memory) > Yes. Would be nice.... >>Next is then which ranges are valid to test, and then things really start >>to get complicated and arch dependant. Which is why I ended up in machdep.c >>right after the setting up of the memory ranges. > > Heh, the above memory mapping is also i386 specific. Alpha only has a small > bit of memory mapped in the loader, same with sparc64, etc. Ehhhh, again more reasons to put this in the kernel, or something that closely resembles a kernel. --WjW From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 21:46:06 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F87916A4CE; Fri, 5 Nov 2004 21:46:06 +0000 (GMT) Received: from mail.net (custpop.ca.mci.com [142.77.1.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0FCE43D58; Fri, 5 Nov 2004 21:46:05 +0000 (GMT) (envelope-from kfl@xiphos.ca) Received: from [216.95.199.148] (account kfl@xiphos.ca HELO [192.168.1.7]) by mail.net (CommuniGate Pro SMTP 4.2.5) with ESMTP id 26469084; Fri, 05 Nov 2004 16:46:04 -0500 Message-ID: <418BF7EA.2020404@xiphos.ca> Date: Fri, 05 Nov 2004 17:00:10 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <418BB008.6040907@xiphos.ca> <418BAE54.72E4208F@freebsd.org> <418BB7BC.3010305@xiphos.ca> <418BB909.501CC9FD@freebsd.org> In-Reply-To: <418BB909.501CC9FD@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Matt Sealey cc: mallman@icir.org cc: Julian Elischer cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 21:46:06 -0000 Ok here is an example, just to make sure I understand: CLI1 : SERVER1 (first connection, option negociated, tuple hash created) CLI1 : SERVER1 (second connection, sending payload in first packet, using previously negotiated cookie) ... CLI1 : SERVER1 ( nth connection, sending payload in first packet, using previously negotiated cookie ) CLI1 : SERVER2 (first connection, option negociated, tuple created) CLI1 : SERVER2 (second connection, sending payload in first packet, using previously negotiated cookie) ... CLI1 : SERVER2 ( nth connection, sending payload in first packet, using previously negotiated cookie ) ... CLIX : SERVERY ( if first connection create cookie, store tuple. if tuple exists send payload in first packet) So, each time CL1 goes to a different server it pay the 3WSH tax only once. This is very alike how T/TCP works right now (beside the cookie thing). What I am wondering is how can we avoid as much as possible the "learning" of the different servers since I know that CLIs will have to go through two gateways running transparent proxies that support the option (T/TCP). But since they are transparent (using forward rules) the gateway don't talk to each other but to the SERVERs (from an IP standpoint). For example, if the cookie was per machine and not tuples, you could have something like this: step 1: CLI1 : SERVER1 (first connection, option negociated, cookie negotiated) CLI1 : SERVER1 (second connection, sending payload in first packet, using previously negotiated cookie) ... step2: CLI1 : SERVER2 (first connection, option negociated, get the same machine cookie from "SERVER1" (found a transparent proxy)) (From now on CL1 assumes its going through a transparent proxy that can do T/TCP) CLI1 : SERVER3 (first connection, sending payload in first packet, using previously negotiated machine cookie, validating transparent proxy) (If the cookie returned by SERVER3 does not match the"machine cookie it found in SERVER1" then go back to step 1) This way the protocol would use knowledge that there is a transparent proxy (found at step2) that is doing T/TCP on behalf of the SERVERs. What do you think? Regards, Andre Oppermann wrote: >Karim Fodil-Lemelin wrote: > > >> In the case where all connections go through the SATLINK and are >>splitted by proxies, it make sense to use this knowledge and not >>renegotiate cookies for every connections since we know there is only >>one path to the internet and that all SATLINK connections will support >>(T/TCP or whatever name it will have). Do you have any plan to include >>that knowledge in your design or is it too much of a special case to >>really care? >> >> > >It does not renegotiate cookies for every connection. Only the first >connection will do that. Re-seeding of the cookies will happen trans- >parently. You pay the 3WSH tax only once for the first connection, or >the first connection after a longer idle time when the cookie expired. > > > -- Karim Fodil-Lemelin Lead Programmer Xiphos Technologies Inc. (514) 848-9640 x223 (514) 848-9644 fax www.xiplink.com -------------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you have received this in error, please contact the sender and delete this communication and any copy immediately. Thank you. From owner-freebsd-arch@FreeBSD.ORG Fri Nov 5 22:17:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D17C16A4CF for ; Fri, 5 Nov 2004 22:17:01 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EF2843D54 for ; Fri, 5 Nov 2004 22:17:00 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 9843 invoked from network); 5 Nov 2004 22:12:51 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Nov 2004 22:12:51 -0000 Message-ID: <418BFBDB.827E347B@freebsd.org> Date: Fri, 05 Nov 2004 23:16:59 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Karim Fodil-Lemelin References: <418BB008.6040907@xiphos.ca> <418BAE54.72E4208F@freebsd.org> <418BB7BC.3010305@xiphos.ca> <418BB909.501CC9FD@freebsd.org> <418BF7EA.2020404@xiphos.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Matt Sealey cc: mallman@icir.org cc: Julian Elischer cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 22:17:01 -0000 Karim Fodil-Lemelin wrote: > > Ok here is an example, just to make sure I understand: > > CLI1 : SERVER1 (first connection, option negociated, tuple hash > created) > CLI1 : SERVER1 (second connection, sending payload in first packet, > using previously negotiated cookie) > ... > CLI1 : SERVER1 ( nth connection, sending payload in first packet, > using previously negotiated cookie ) > > CLI1 : SERVER2 (first connection, option negociated, tuple created) > CLI1 : SERVER2 (second connection, sending payload in first packet, > using previously negotiated cookie) > ... > CLI1 : SERVER2 ( nth connection, sending payload in first packet, > using previously negotiated cookie ) > ... > CLIX : SERVERY ( if first connection create cookie, store tuple. if > tuple exists send payload in first packet) > > So, each time CL1 goes to a different server it pay the 3WSH tax only > once. This is very alike how T/TCP works right now (beside the cookie > thing). Yes, exactly. Actually the new T/TCP thing works the same as the old one from a functional point of view. What changes is the implementation. The original one was quite intrusive to the TCP code and generated many special cases which made it hard to maintain and to put new code in. In addition it CC* stuff is a rather weak and fragile mechanism. That's why we go with cookies this time and there are only a few places where the code has to be aware of it. Much less intrusive and more easy to maintain properly. > What I am wondering is how can we avoid as much as possible the > "learning" of the different servers since I know that CLIs will have to > go through two gateways running transparent proxies that support the > option (T/TCP). But since they are transparent (using forward rules) the > gateway don't talk to each other but to the SERVERs (from an IP standpoint). > > For example, if the cookie was per machine and not tuples, you could > have something like this: > > step 1: > CLI1 : SERVER1 (first connection, option negociated, cookie negotiated) > CLI1 : SERVER1 (second connection, sending payload in first packet, > using previously negotiated cookie) > ... > step2: > CLI1 : SERVER2 (first connection, option negociated, get the same > machine cookie from "SERVER1" (found a transparent proxy)) > > (From now on CL1 assumes its going through a transparent proxy that can > do T/TCP) > > CLI1 : SERVER3 (first connection, sending payload in first packet, > using previously negotiated machine cookie, validating transparent proxy) > > (If the cookie returned by SERVER3 does not match the"machine cookie it > found in SERVER1" then go back to step 1) > > This way the protocol would use knowledge that there is a transparent > proxy (found at step2) that is doing T/TCP on behalf of the SERVERs. > > What do you think? I think that is nice. Sounds like homework for you. ;-) -- Andre > Regards, > > Andre Oppermann wrote: > > >Karim Fodil-Lemelin wrote: > > > > > >> In the case where all connections go through the SATLINK and are > >>splitted by proxies, it make sense to use this knowledge and not > >>renegotiate cookies for every connections since we know there is only > >>one path to the internet and that all SATLINK connections will support > >>(T/TCP or whatever name it will have). Do you have any plan to include > >>that knowledge in your design or is it too much of a special case to > >>really care? > >> > >> > > > >It does not renegotiate cookies for every connection. Only the first > >connection will do that. Re-seeding of the cookies will happen trans- > >parently. You pay the 3WSH tax only once for the first connection, or > >the first connection after a longer idle time when the cookie expired. > > > > > > > > -- > Karim Fodil-Lemelin > Lead Programmer > > Xiphos Technologies Inc. > (514) 848-9640 x223 > (514) 848-9644 fax > www.xiplink.com > > -------------------------------------------------------------- > The information transmitted is intended only for the > person or entity to which it is addressed and may contain > confidential and/or privileged material. If you have > received this in error, please contact the sender and delete > this communication and any copy immediately. Thank you. From owner-freebsd-arch@FreeBSD.ORG Sat Nov 6 23:39:22 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1DBF16A4D2 for ; Sat, 6 Nov 2004 23:39:22 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 153FA43D1D for ; Sat, 6 Nov 2004 23:39:22 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id iA6NdKiF010848 for ; Sun, 7 Nov 2004 00:39:20 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Sun, 07 Nov 2004 00:39:20 +0100 Message-ID: <10847.1099784360@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: Multi-threading access to device drivers. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2004 23:39:22 -0000 Assume a device driver which is not Giant-handicapped. Assume an I/O path which does not need Giant to get from read(2) to the device driver. Assume a SMP machine. Assume a process with two threads on two CPUs, both doing read(fd, buf, len) at the same time. Should we let both reads into the driver at the same time ? If so, which uio_offset do we hand them ? -- 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.