From owner-freebsd-arch Sun May 28 5:24:55 2000 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 608) id C8FED37B644; Sun, 28 May 2000 05:24:53 -0700 (PDT) From: "Jonathan M. Bresler" To: cp@bsdi.com Cc: arch@freebsd.org In-reply-to: <200005261859.MAA15375@berserker.bsdi.com> (message from Chuck Paterson on Fri, 26 May 2000 12:59:49 -0600) Subject: Re: Sorry, SMPng tracing Message-Id: <20000528122453.C8FED37B644@hub.freebsd.org> Date: Sun, 28 May 2000 05:24:53 -0700 (PDT) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I didn't realize the trace was near as big as it was. > > Chuck that's okay (?). majordomo limits inbound email to 40,000 bytes so the email was canned. i have raised the limit to 100,000 bytes. please consider making large files available by ftp/http and sending the url to the list. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 28 22:58: 3 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 8C50D37BB97 for ; Sun, 28 May 2000 22:57:59 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id BAA389542 for ; Mon, 29 May 2000 01:57:57 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Mon, 29 May 2000 01:58:01 -0400 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: some lpr changes: background Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. I'm a systems programmer at RPI (Troy NY), and back in the early 90's we migrated most of campus computing from a mainframe to unix workstations. We started off with both Sun and IBM workstations, and needed a printing system that would work the same on both platforms. Someone found a bsd-ish lpr "on the net" and we got that running on AIX and probably SunOS (pre-Solaris). In the mid-nineties I took that over, adding support for newer versions of AIX, Solaris, and later IRIX. We also added a bunch of other customizations, as various needs arose. I did some net searching of my own, and of the lpr's I could find at the time, ours seemed to be the closest to FreeBSD's. I meant to merge the two, but other events pretty much tied up my schedule. I am now getting back to doing that, and I see people have made a LOT of improvements in the meantime! I've now caught up with enough of those changes that I should be able to start to writing updates for freebsd's current source to add features we've had here. Our environment is that we have a few hundred workstations which share the exact same userid space (via AFS). We have some more workstations which do not have the same userid's, but do want to print. We have well over 200 print queues, but I think only about 150 of them are used enough to notice. We have one samba-based server accepting jobs from PC users. We have four or five main print servers (and the samba server is not one of them...). Most of the print servers accept jobs from Mac users via CAP (eew), and most of the print queues are driven via CAP/ethertalk (at least at the moment). The vast majority of our printers are networked Postscript printers (obviously, given the CAP angle...). Printers range from simple B&W lasers, to expensive color printers, to big color plotters (HP DesignJet and Phaser 600). One very important criteria for us is that we have to be able to charge users on a per-job basis for what they've printed. It's amazing how many people "need" listings of all X manuals if they can print for free, and how no one needs them all if we charge 5 cents a page... So, I'd like to contribute at least some of these RPI-ish changes back to freebsd (as I sort them out...), just because I think they could be useful for other people. I am aware of lprNG, which is popular among many "heavy-duty printing" sites (in fact, it is used by the CS dept at RPI). The irony is that I may very well switch over to lprNG after getting all these updates sorted out, but I'd still like to sort them out just because I'd hate to see them all thrown away. I'd like to start up a discussion with any FreeBSD'ers who do use the default lpr to handle a lot of printing. I'm not sure this mailing list is the best place for that, but it was suggested so I'll try it here. Note that I'm interested in both updating the FreeBSD lpr, and in having a separate-ish package for lpr that someone could install on other OS's (after all, almost all the machines I'm running this on are NOT freebsd...). I sometimes think of this as the "lpr:ce" project, compared to "lpr:ng". The Sci Fi network had "Star Trek: Classic Edition", where they took the original star trek episodes and spruced them up. That's basically what I want to do. In my own mind, anyone who wants really heavy-duty printing should probably still dive into lprNG. I do not intend to work as hard as Patrick does. Also, there's probably a question of how to best feed these changes into freebsd. If I do a PR for each of them, I'm going to drive some committers crazy. At the same time, it would be prudent for several others to test these, since almost all of my real-world (production) testing is on non-FreeBSD machines. I'll send a separate message with a list of some of the changes we have made... It'll probably be a bit long. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 28 23: 1:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 2005B37BB97 for ; Sun, 28 May 2000 23:01:29 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id CAA107914 for ; Mon, 29 May 2000 02:01:27 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Mon, 29 May 2000 02:01:31 -0400 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: some lpr changes: examples (LONG) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG While I am now a lot closer to freebsd's current source than I was two months ago, things still aren't sorted out to the point that I could just point to a list of diff's. So, I want to list out some of our changes, and let people tell me which ones people would like to see first. We've added two new printcap values, 'ss=' and 'sr='. These specify files to use for "transfer statistics". 'sr' tracks print-data files as they are received from other hosts, 'ss' tracks print-data files are they are sent (usually via the standard lpd protocols) to some other host (usually the real printer). They serve different purposes (for me, at least). Sometimes our print servers slow down due to network problems, but usually I don't notice until the performance is really abysmal. And even when I *do* finally notice, I have no way of saying when the problem started, or whether it was a gradual problem or if it suddenly appeared. Tracking how fast jobs PRINT is not useful for this, because there are so many things which can effect that (have you ever printed 3D PS files from matlab? ouch). But if the print servers track transfer times of files coming INTO the print server, that should be a good measure of network performance. Not only that, but it can show if a problem is a general problem (from everywhere on campus), or if it's only happening from some hosts. so, 'sr' is really a network-diagnosing tool. And all these log files are on the print server, which is the machine we beef up with plenty of extra disk space. 'ss' is a poor-man's accounting record. We don't get information on pages-printed, but at least we know WHO printed which job at what time, in case someone is dumping large jobs to one of these printers. Since MOST of our queues are driven by CAP, only a few queues use this feature. 'sr' and 'ss' produce records in the same format, for ease in processing. Record includes a timestamp (in the format '%Y.%m%d.%H%M%S%Z.a', which makes it easy to sort or skip over, but still contains all the info one might want in an easily "eyeball-able" form). Some other fields are queue-name, originating host-name, job-id, file-count (for jobs which include multiple files, there's one record per file), userid, bytecount, transfer-time (seconds), transfer-rate (KBytes/sec), and a few other things. I'll skip over some details on this. Note that you might think you could do these 'ss' records via some filter specified as 'if='. That doesn't work. The filter gets executed to copy the original file to a new file, and *then* lpd transfers the new file to the other host. When the 'if=' filter is running, it can have NO idea of transfer times, or even if the destination printer is even up. - - - The current freebsd has the notion of a canonical printername. If a printcap entry has multiple names, it is assumed that the first name is the canonical one. At RPI, we basically have two canonical names. The "pretty-print" (long, descriptive, and in mixed-case) name, and the "easy-to-type" short name (always all lowercase, always less than 9 characters). I've changed some of lpr's references of 'pp->printer' (which is our long name, up to 32 characters), to this new 'pp->short_name'. For some messages, we do want the long name, and for others (like the above statistics records...), we'd really much rather have the short name. I'm still sorting out which name should be in which message, but it's basically "long name to user, short name to log files"... I'm also thinking that maybe I should just rename 'pp->printer' variable to 'pp->long_name', so it'd be obvious you're making an explicit decision as to which name to use. If a printcap entry has only one name, both fields are set to the same string. At RPI, the "pretty" name is always the first in the list, and the "short lc" name is always the last one. If this update was picked up, I'd probably have to do something which didn't make that assumption. Not sure what would be best... - - - How do people handle all the input filters one can set in a printcap entry? Historically I have setup the printcap entry which actually drives the printer so that 'if=', 'cf=', et al are set to separate scripts. Now, those scripts are really just eight copies of the exact same script. That script, in turn, looks at $0 to tell which filter it is supposed to act like, and does a 'case' statement based on that. I think I picked this up from some CAP examples. Recently it occurred to me that this is pretty stupid. Not only that, but it does not work when people use an 'if=' filter to send jobs to a remote printer (because for remote printers, lpd only checks for 'if=', and ignores all the rest). I don't know how good the lpd interface is on your Laser printers, but mine doesn't know what to do about 'dvi' files or some of the other special cases we use... So, I added a 'jf=' entry, which is meant to say "default per-job filter". If it is set, then that value is used for all per-job filters which are not explicitly set in that printcap entry. Furthermore, I export an environment variable which indicates which filter the script is being called for. LPD_SCRIPT is set to values like "standard", "fortran", "dvi", etc. You'd have to change your filter scripts to take advantage of this, but the idea is that this change can go into lpr without changing anything in anyone's current setup, and people can move to it as they feel like it. (if they feel like it). Note that the value given for 'jf=' is (obviously) not used to set a value for 'of='... - - - There are a lot of other things I put into environment variables, for the benefit of the scripts one might run. I use them for my CAP scripts, for instance. (while I have a lot of interesting changes to CAP, I should warn that my CAP sources are a hybrid mess of changes, and thus would probably take a long time to come up with diff's for CAP that others could use...). I add things like: LPD_DF_FILE - the current datafile name (I forget what I do with this in the script, it might be that I don't actually use this anymore...). LPD_ERRFILE - the temporary file lpd uses for error messages. It may be this is only useful due to other changes I have in lpd... LPD_EMAILFILE - similar to the error file, our lpd now creates a temp file for holding a message to send back to the user. Our CAP is setup to put error messages or other useful info in this, and after CAP is done then lpd emails the contents of this (if it isn't empty) back to the user. LPD_FILTER - already described... LPD_WANTHDR - indicates whether LPD thinks a header page should be printed for this file. (note that a single "print job" may consist of multiple files, and the input filter is started for each file, not once per job). This reflects things like '-h' and 'sh' too. (for our plotters, the "header box" is printed by the if= filter, not the of= filter). LPD_PSONLY - hmm, I'll skip the details on this for now. LPD_PTRTYPE, LPD_PTRSTYPE - indicate printer type and subtype, as picked up from the printcap entry (if they were set). Type is set by 'ty=' (inspired from what NeXTSTEP used...), subtype is set by 'sy=' (which is my own invention...) LPD_USERID - userid of original user. Yes, I know this is already passed as an explicit parameter. LPD_ORIGHOST - host which originated the print job. LPD_USERACCT - Hmm, I think this is the name of the accounting file to write records to. LPD_JOBISPS - Since almost all of our printers are postscript, it is nice to know if the current script is already postscript. lpd figures this out and sets the environment variable, instead of having every script do handsprings to figure it out. LPD_JOBNUM - the job number for this job, ie, what the user sees in the 'Job' column in 'lpq'. This makes sure the accounting records (from CAP, in my case) includes the same number that the user remembers from lpq. LPD_FILENO - file number within the current job. Our cap also stuffs this in the accounting record (we have some printers where we have a "per-job" charge, and we only want to charge that once PER JOB, not once per file in a job...). LPD_JOBNAME - what the user set for jobname (-J). LPD_CLASS - what the user set for class (-C) LPD_CLAIMEDUSER - I'll skip the details on this for now LPD_EMAILTO - who to send email to. I'm pretty sure I don't use use this anymore, since lpd sends the email. LPD_XHEADER, LPD_XINITIAL, LPD_XFORCED, LPD_X_OPT - I'll skip this for now, but I think this is basically the same idea as lprNG now has with "Z-options". RPI has had the "X-options" ("extended options") since about 1995, but most of the implementation is based on how I have our CAP setup to work. I also intend to add that timestamp value (the one for ss=/sr=) as an environment variable, so the filter (CAP in my case) can report the exact same timestamp for the file that lpd is using. - - - We have something called "printset" files, which a user or administrator can use to set the default printer for lpr, lpq, lprm. If no printer is specified by the user, then 'lpr' (etc) will first check for a "session printset file" (which probably won't make sense outside of RPI), and then a "user printset file", and lastly a "host printset file". This way we have different default printers in different public labs, but the user just types 'lpr' if they want the "right" one (because we've set up /etc/printset files on those machines). Besides defining the "default" printer, these printset files define pseudo-printers called 'PS' and 'COLORPS' (or something like that). So, we can install applications and tell them to print to 'PS' or 'COLORPS', and the user can control where that output will go. We needed this because we had a few X applications early on which were a real headache to change the printer inside the application... - - - For the past few years, I've had something called linked queues "almost" implemented. They were pretty much implemented everywhere except for lpd. They are also pretty much worthless without the support in lpd... :-) The idea was to create a single "fake" queue for users to send to, and then the print server could link that queue to one or more real queues. In particular, we'd handle high-volume queues by buying multiple identical printers, and have jobs from users spread over the different real printers. If one printer died, or ran out of paper, or whatever, operators could stop that printer and jobs would automatically go to whatever printers were still up. I ran into a brick wall on this because all kinds of printer-specific variables inside lpd were global variables at the time, and trying to correctly manipulate them all was a mess. Thanks to all the recent changes to freebsd's lpr, these are now all in a struct, which will make this a whole lot easier to implement! Thanks! I know lprNG has something like this, but I can't think of the name used for it right now... - - - I also have "exclusive queues". This is where you have one physical device (in our case, a plotter), and multiple exclusive queues which use it (in our case, "standard paper" or "glossy paper" -- but the plotter can only be set up for one or the other at any given moment). All "exclusive queues" mean is that you can not start one of the queues unless all of the related queues are already stopped. This is another thing that has been half-implemented for years, and I hope to get back to now. - - - I'm now also thinking of "merged queues", but since I haven't even started on that there's probably not much point in describing it... The idea is to handle printers which have several different types of paper trays. All of them CAN be active at once, but I'm sure we'll have times when we'll be out of one (say, "transparencies"), so we'd want to 'stop' those jobs while letting all the other jobs through. I must admit I've just starting thinking how I want this to work, so maybe this will wait until I move to lprNG. - - - I added two more signal handlers to lpd, -USR1 and -USR2. They can be used to raise or lower the logging-level ("lflag") without having to restart the daemon. There is also now a table for logging levels associated with the "cmdname" table in lpd. Recvjob, printjob, and rmjob are all logged once 'lflag' is 1. The display-job commands are only logged when lflag is increased to two. Our print servers always run with lflag set to one, so we can track things (if problems come up). - - - We use an automatic procedure (called "package") to update our system disks. If you have a busy print server, then killing and restarting lpd (due to a new lpd) can be tricky. I added an option to 'lpd' so that it will use 'SO_REUSEADDR' when trying to bind to the print socket. This happens if '-R' is included when starting up lpd. I must admit that I'm not sure this was the best solution, but it DID solve the problem we were having when automatically installing and restarting lpd. Still, it's an option, so at least it doesn't happen unless you ask it to :-) - - - In 'lpc', the 'clean' command currently makes decisions based on some assumptions it makes about filenames in the spool directory. In particular, it assumes that a file called 'df[A-Z]' should have a matching control file named 'cfA'. This is, in fact, a bad assumption, for two reasons: 1. when creating a data-file (df...), lpd uses the hostname the machine currently uses. however, when RECEIVING a control file, lpd uses the hostname of the *connection* the file is coming in on. Thus, on a host with multiple interfaces, you can end up with datafiles based on one interface, and the control files based on another one. As luck would have it, we used to have one such machine, and I did an 'lpc clean' on a busy print server, and that wiped out over a hundred waiting print jobs (last week of classes). I was not popular... 2. due to printers dieing, we sometimes accept jobs on one print server only to bounce them to a second print server. When this happens, the datafile is the original host, and the control file is the named based on that middle print server. Since I was *very* unpopular after that 'lpc clean', I made a few changes to address this. For one, 'lpc clean' will only remove files which are more than an hour old. Thus, even if the names are out-of-sync, it is much less likely you'll kill a job. For two, I keep track of hosts which are "under our control" (ie, all of which are using the same set of userids). For those hosts, lpd does not change the hostname on an incoming control file to match the connection it is coming in on. Thus, the cf file does (generally) still match the df filename. For three, I added a 'tclean' command to lpc. It tells you what 'clean' would do without actually deleting any files. I made a few other changes to 'clean' while I was at it. Caveat: While I am nearly caught up with freebsd's lpr for most things, I'm still way-out-of-date on 'lpc', so these changes are probably the farthest away from being usable... - - - lpr has a status file it uses to hold information about the status of a given print queue. I have it tack on 'extended' to that filename, and have CAP (or whatever the print filter is) put "extended status" information into that file. 'lpq' will include this "extended status" line if the user specifies 'lpq -l' (long). - - - I have lpd setting the value in that status file in a number of extra places in it's processing too. I've gone on a few wild goose changes on some problem because the status message implied lpd was stuck in one section while it was really stuck somewhere else. I also changed 'lpc' so operators could SET a status message (when a printer is down, for instance). - - - I'm also in the process of providing a web interface to 'lpq' and 'lprm'. While most of that will probably be RPI-specific, I am thinking of making an alternate display format which would be easier for a script to parse, and would include more info. Note that this will NOT spit out HTML, it would just print out info in a format that will be easier for a CGI script to turn into HTML. In my case, the script notices if the web-user (authenticated via https) owns a particular job in the queue listing, and if so it adds a link the user can use to delete that job. Still in the early stages, but it seems to work pretty well. - - - Related to the web-page project, I've changed lpq and lprm to allow '-Pqueue@hostname'. The queue has to match a queue in the current host's printcap file, but you can ask for the status on that queue on a particular host. The reason for this is that we would have one server which is our heavy-duty CGI web server. For any given queue, a PC user might want to check the queue's status from the samba server, or a Mac user might want to check it from one of the hosts which is accepting print jobs from Macs. We do have times where a print server is so backed up that jobs are still on the originating host (eg, samba), and if people don't see their job in the queue listing then they just send it again. Lpr also recognizes '-Pqueue@hostname', and just ignores the @hostname part (IIRC). I probably should abort instead. In any case, my thinking is that I don't want people to be able to DIRECT their print jobs to some specific host, but I want to be able to check and remove jobs. That's how it works right now. I hope to soon add a config file, probably called '/etc/hosts.lpd-dest', which would have a line in it for "destination-specific' host information. Then I'd limit the @hostname to hosts specifically named in that file. - - - We had some linux users on campus who were sending print jobs with no "filterline" specified. The control file would have unlink lines for all the data files which were set, but it wouldn't include any instructions of what to do with those files except to unlink them. Since I have no administrative control over that host, and since I didn't know enough about linux to tell him what to do, I changed our lpd to recognize this situation. If a control file would print out zero files, but it would also unlink one or more files, then I have lpd first print out all the files it would unlink using the standard ('if=') filter. This seems to have solved the problem for some linux users. - - - Freebsd's lpr currently recognizes a 'rg=' attribute to indicate the printer is restricted to a certain group of users (ie, a group name from /etc/group). I expanded upon this to add 'ru=', 'xg=', and 'xu=' attributes. I also changed 'rg=' to accept more than one group. So: rg= one or more groups of users. if specified, the printer is limited to these users in these groups. ru= one more more userids. xg= one or more groups of users. If specified, the users in these groups are NOT allowed to use the printer. xu= one or more userids. If specified, these userids are NOT allowd to use the printer. There is a hierarchy to how these are processed, but I forget the exact order right now. But you could use a group for one set of people (say "all people in dept X"), and then exclude some specific bad-actors out of that group using xu or xg. These were done this way because we had a department with several different printers, and they wanted all their faculty to print to all those printers, but a different list of allowed students for each one. I didn't want to have to ten different /etc/groups, where most of the people in any one group were in all the other groups too. Also, we (the computer center) could automatically generate the appropriate list of faculty, while the list of students would be something the department kept up "by hand". The irony is that after using this for a year or two, the dept decided it was easier to just let everyone use the printer, because they couldn't remember to update the various lists of which students were allowed to print to which printer... - - - One of the OS's we run this on (Solaris?) didn't have bsd-style signal processing, or it didn't work quite the way I wanted it, so I have an update to use posix-based signals (sigaction, etc) based on a compile-time setting. I imagine I should just switch to using posix signals for all platforms, but I don't know how well those are supported on other OS's. - - - Well, I'm sure there are other changes in RPI's lpr that I'd like to sort out, but I'm ready to call it a day at this point. I also have a number of changes in the back of my head that I have not written yet, but I'd rather start with things I already have working in some form. I'm also interested in seeing what other changes might interest me from other places (netbsd, openbsd, etc), just so freebsd's lpr "plays well" with the others. Similarly, I have a linux (redhat) system I can check against. While this may all sound interesting, I'm not making any promises on how rapidly I could produce the usable updates for all of them! Apologies if this is too long or too specialized for arch... --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 30 10: 2:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 63E9D37BC90 for ; Tue, 30 May 2000 10:02:24 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.10.1/8.10.1) id e4UH2MX14070; Tue, 30 May 2000 13:02:22 -0400 (EDT) Date: Tue, 30 May 2000 13:02:22 -0400 (EDT) From: Luoqi Chen Message-Id: <200005301702.e4UH2MX14070@lor.watermarkgroup.com> To: cp@bsdi.com Subject: Re: Preemptive kernel on older X86 hardware Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The two types of mutex (spinning and sleeping) are quite different. A spinning mutex is owned by a cpu, and degenerates into a no-op when ncpu == 1; on the other hand, a sleeping mutex is owned by a thread and is nontrivial for UP preemptive kernels. IMHO, it is a good idea to have a separate implementation for each type, for example, we don't need to deal with priority inversion in the spinning case (the thread that holds the spinning mutex should not be preempted). -lq > On Thu, 25 May 2000, Chuck Paterson wrote: > > > } > > } Lets use subroutines during development at least, it will make > > } things easier. I don't think anyone can argue with that :-) > > } > > > > Almost.) I certainly think that the actually locking > > stuff can be in a function but we really want to wrap the > > function in a macro so we can put tracing in. Being able > > to look at a trace and see file and line numbers for mutex > > locks and unlocks is invaluable. > > Absolutely. If using functions, it might also be a good idea to wrap with > an inline which checks for M_SPIN or M_DEF and calls a different > implementation function for each. This might allow a slightly more > efficient implementation. > > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 30 10:16: 8 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 82F2037BC90 for ; Tue, 30 May 2000 10:16:03 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@localhost [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id LAA27213; Tue, 30 May 2000 11:15:54 -0600 (MDT) Message-Id: <200005301715.LAA27213@berserker.bsdi.com> To: Luoqi Chen Cc: arch@freebsd.org Subject: Re: Preemptive kernel on older X86 hardware From: Chuck Paterson Date: Tue, 30 May 2000 11:15:54 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A spin lock can only degenerates to a nop when it is known that it is held only by top half threads. It is true that there is no reason for spin and non-spin mutexs to share any of the implementation. In the case of BSD/OS no code is shared. I try not to use the term sleep when describing a mutex because this leads people to believe that the process ends up on a sleep(9) queue. Chuck ----- Begin Included Message ----- Date: Tue, 30 May 2000 13:02:22 -0400 From: Luoqi Chen To: cp@bsdi.com Subject: Re: Preemptive kernel on older X86 hardware cc: arch@FreeBSD.ORG The two types of mutex (spinning and sleeping) are quite different. A spinning mutex is owned by a cpu, and degenerates into a no-op when ncpu == 1; on the other hand, a sleeping mutex is owned by a thread and is nontrivial for UP preemptive kernels. IMHO, it is a good idea to have a separate implementation for each type, for example, we don't need to deal with priority inversion in the spinning case (the thread that holds the spinning mutex should not be preempted). -lq > On Thu, 25 May 2000, Chuck Paterson wrote: > > > } > > } Lets use subroutines during development at least, it will make > > } things easier. I don't think anyone can argue with that :-) > > } > > > > Almost.) I certainly think that the actually locking > > stuff can be in a function but we really want to wrap the > > function in a macro so we can put tracing in. Being able > > to look at a trace and see file and line numbers for mutex > > locks and unlocks is invaluable. > > Absolutely. If using functions, it might also be a good idea to wrap with > an inline which checks for M_SPIN or M_DEF and calls a different > implementation function for each. This might allow a slightly more > efficient implementation. > > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 20 8442 9037 ----- End Included Message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 31 6: 4:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 2A94737B8EA for ; Wed, 31 May 2000 06:04:32 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id GAA26552 for ; Wed, 31 May 2000 06:04:29 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda26550; Wed May 31 06:04:10 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id GAA79767 for ; Wed, 31 May 2000 06:04:09 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdw79765; Wed May 31 06:04:01 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.10.1/8.9.1) id e4VD40n08288 for ; Wed, 31 May 2000 06:04:00 -0700 (PDT) Message-Id: <200005311304.e4VD40n08288@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdkc8284; Wed May 31 06:03:41 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.0-STABLE X-Sender: cy To: arch@freebsd.org Subject: More or Less and GNU Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 May 2000 06:03:41 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've noticed some commits to -current and ports over the last week that indicate that Berkeley more is being replaced by GNU less. Granted less is a better product and I use it myself, my question is about GNU licensing. First, from the standpoint of GNU licensing this is a bad thing. Secondly, I've seen numerous discussions on various mailing lists about why not to do something or another because of GNU licensing, yet we replace applications with Berkeley licenses with GNU licenses. Why are we then so concerned with GNU licensing in the first place when we so quickly replace a Berkeley application with a GNU application, especially when, at least as far as the features I use, behave so closely? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 31 6: 6:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id BF7E837B84B for ; Wed, 31 May 2000 06:06:52 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id PAA37906; Wed, 31 May 2000 15:06:35 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Cy Schubert - ITSD Open Systems Group Cc: arch@FreeBSD.ORG Subject: Re: More or Less and GNU In-reply-to: Your message of "Wed, 31 May 2000 06:03:41 PDT." <200005311304.e4VD40n08288@cwsys.cwsent.com> Date: Wed, 31 May 2000 15:06:35 +0200 Message-ID: <37904.959778395@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200005311304.e4VD40n08288@cwsys.cwsent.com>, Cy Schubert - ITSD Ope n Systems Group writes: >I've noticed some commits to -current and ports over the last week that >indicate that Berkeley more is being replaced by GNU less. Granted >less is a better product and I use it myself, my question is about GNU >licensing. Look at; /usr/src/contrib/less/LICENSE It contains a 2 clause BSD license... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 31 6: 9:27 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id 2B39837B882 for ; Wed, 31 May 2000 06:09:20 -0700 (PDT) (envelope-from nbm@sunesi.net) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 12x8F0-000BvW-00; Wed, 31 May 2000 15:08:58 +0200 Date: Wed, 31 May 2000 15:08:58 +0200 From: Neil Blakey-Milner To: Cy Schubert - ITSD Open Systems Group Cc: arch@freebsd.org Subject: Re: More or Less and GNU Message-ID: <20000531150858.A45800@mithrandr.moria.org> References: <200005311304.e4VD40n08288@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200005311304.e4VD40n08288@cwsys.cwsent.com>; from Cy.Schubert@uumail.gov.bc.ca on Wed, May 31, 2000 at 06:03:41AM -0700 Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed 2000-05-31 (06:03), Cy Schubert - ITSD Open Systems Group wrote: > I've noticed some commits to -current and ports over the last week that > indicate that Berkeley more is being replaced by GNU less. Granted > less is a better product and I use it myself, my question is about GNU > licensing. 'less' is distributable under the 'less' license, which is more-or-less (ug!) BSD-license-equivalent. The less README file says: This program is free software. You may redistribute it and/or modify it under the terms of either: 1. The GNU General Public License, as published by the Free Software Foundation; either version 2, or (at your option) any later version. A copy of this license is in the file COPYING. or 2. The Less License, in the file LICENSE. The less LICENSE file says: Copyright (C) 1984-2000 Mark Nudelman Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice in the documentation and/or other materials provided with the distribution. Neil -- Neil Blakey-Milner Sunesi Clinical Systems nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 31 6:37:48 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id E4D2F37BE79 for ; Wed, 31 May 2000 06:37:43 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id GAA26664; Wed, 31 May 2000 06:30:29 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda26661; Wed May 31 06:30:18 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id GAA80019; Wed, 31 May 2000 06:30:18 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdD80017; Wed May 31 06:30:03 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.10.1/8.9.1) id e4VDU2F09906; Wed, 31 May 2000 06:30:02 -0700 (PDT) Message-Id: <200005311330.e4VDU2F09906@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdsh9890; Wed May 31 06:29:10 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.0-STABLE X-Sender: cy To: Poul-Henning Kamp , Neil Blakey-Milner Cc: Cy Schubert - ITSD Open Systems Group , arch@FreeBSD.ORG Subject: Re: More or Less and GNU In-reply-to: Your message of "Wed, 31 May 2000 15:06:35 +0200." <37904.959778395@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 May 2000 06:29:10 -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <37904.959778395@critter.freebsd.dk>, Poul-Henning Kamp writes: > In message <200005311304.e4VD40n08288@cwsys.cwsent.com>, Cy Schubert - ITSD O > pe > n Systems Group writes: > >I've noticed some commits to -current and ports over the last week that > >indicate that Berkeley more is being replaced by GNU less. Granted > >less is a better product and I use it myself, my question is about GNU > >licensing. > > Look at; > > /usr/src/contrib/less/LICENSE > > It contains a 2 clause BSD license... Thanks. I should have looked before assuming that it had the GNU license. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 31 7: 5: 2 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp13.bellglobal.com (smtp13.bellglobal.com [204.101.251.52]) by hub.freebsd.org (Postfix) with ESMTP id 4380937B86F for ; Wed, 31 May 2000 07:04:58 -0700 (PDT) (envelope-from hoek@FreeBSD.org) Received: from orange (Hamilton-ppp44877.sympatico.ca [206.172.76.70]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id KAA28434; Wed, 31 May 2000 10:08:44 -0400 (EDT) Received: (from tim@localhost) by orange (8.9.3/8.9.1) id KAA96812; Wed, 31 May 2000 10:04:50 -0400 (EDT) (envelope-from tim) Date: Wed, 31 May 2000 10:04:49 -0400 From: Tim Vanderhoek To: Cy Schubert - ITSD Open Systems Group Cc: arch@FreeBSD.org Subject: Re: More or Less and GNU Message-ID: <20000531100449.C96286@orange> References: <200005311304.e4VD40n08288@cwsys.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <200005311304.e4VD40n08288@cwsys.cwsent.com>; from Cy Schubert - ITSD Open Systems Group on Wed, May 31, 2000 at 06:03:41AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, May 31, 2000 at 06:03:41AM -0700, Cy Schubert - ITSD Open Systems Group wrote: > > Granted > less is a better product Some of us would debate this if it weren't a waste of time. -- Signature withheld by request of author. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 31 7:38:10 2000 Delivered-To: freebsd-arch@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.2.163]) by hub.freebsd.org (Postfix) with ESMTP id F05D137B81A for ; Wed, 31 May 2000 07:38:05 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 12x9ct-000N2w-00; Wed, 31 May 2000 16:37:43 +0200 From: Sheldon Hearn To: Tim Vanderhoek Cc: Cy Schubert - ITSD Open Systems Group , arch@FreeBSD.ORG Subject: Re: More or Less and GNU In-reply-to: Your message of "Wed, 31 May 2000 10:04:49 -0400." <20000531100449.C96286@orange> Date: Wed, 31 May 2000 16:37:42 +0200 Message-ID: <88593.959783862@axl.ops.uunet.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 31 May 2000 10:04:49 -0400, Tim Vanderhoek wrote: > > Granted less is a better product > > Some of us would debate this if it weren't a waste of time. Well, it _will_ be once you've submitted your enhancements to the maintainer. Then we'll have the most of both worlds. ;-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 31 9:24:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from viking.sophos.com (viking.sophos.com [193.82.145.128]) by hub.freebsd.org (Postfix) with ESMTP id 0D58F37B5E8 for ; Wed, 31 May 2000 09:24:55 -0700 (PDT) (envelope-from tmb@tyne.sophos.com) Received: from tyne.sophos.com (tyne.sophos.com [193.82.145.132]) by viking.sophos.com (Postfix) with ESMTP id 0354B45C41; Wed, 31 May 2000 16:24:51 +0000 (GMT) Received: (from tmb@localhost) by tyne.sophos.com (8.9.3/8.9.3) id RAA07570; Wed, 31 May 2000 17:24:32 +0100 (BST) (envelope-from tmb) Date: Wed, 31 May 2000 17:24:32 +0100 From: Mark Blackman To: Chuck Paterson Cc: Luoqi Chen , arch@freebsd.org Subject: Re: Preemptive kernel on older X86 hardware Message-ID: <20000531172432.A7547@sophos.com> References: <200005301715.LAA27213@berserker.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200005301715.LAA27213@berserker.bsdi.com>; from cp@bsdi.com on Tue, May 30, 2000 at 11:15:54AM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On a nearly unrelated note, anybody care to venture how tough would it be to modify *BSD* to run on a NUMA system instead of an SMP solution. This, obviously, is very high-end tiny niche area, but interesting to contemplate, especially if you're not doing the development. :) -- Mark Blackman,Internet Systems Administrator,Sophos Anti-Virus e-mail: tmb@sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 31 11:30:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns.dotcast.net (ns.dotcast.com [63.77.78.58]) by hub.freebsd.org (Postfix) with ESMTP id 36B4737B548 for ; Wed, 31 May 2000 11:30:40 -0700 (PDT) (envelope-from marty@dotcast.com) Received: from joshuatree (joshuatree.dotcast.com [10.10.10.133]) by ns.dotcast.net (8.9.3/8.9.3) with SMTP id LAA80061 for ; Wed, 31 May 2000 11:30:19 -0700 (PDT) (envelope-from marty@dotcast.com) From: "Marty Fouts" To: Subject: RE: Preemptive kernel on older X86 hardware Date: Wed, 31 May 2000 11:29:32 -0700 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.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <20000531172432.A7547@sophos.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It depends a great deal on how you want to use the NUMA system and what it's internal architecture supports. I spent a number of years at HP Labs investigating a similar proposition for a different Un*x, and the amount of work varies dramatically with the requirements. Loosely coupled "cluster" applications mostly require adding some shared namespace features, which is a lot of work. Tightly coupled highly available systems pretty much require a significant rewrite, or, lacking that, a collection of bubble gum and bailing wire sufficient to stretch from here to the moon and back. Marty -----Original Message----- From: owner-freebsd-arch@FreeBSD.ORG [mailto:owner-freebsd-arch@FreeBSD.ORG]On Behalf Of Mark Blackman Sent: Wednesday, May 31, 2000 9:25 AM To: Chuck Paterson Cc: Luoqi Chen; arch@FreeBSD.ORG Subject: Re: Preemptive kernel on older X86 hardware On a nearly unrelated note, anybody care to venture how tough would it be to modify *BSD* to run on a NUMA system instead of an SMP solution. This, obviously, is very high-end tiny niche area, but interesting to contemplate, especially if you're not doing the development. :) -- Mark Blackman,Internet Systems Administrator,Sophos Anti-Virus e-mail: tmb@sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 31 19:38:34 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rdc1.tx.home.com (ha2.rdc1.tx.home.com [24.4.0.67]) by hub.freebsd.org (Postfix) with ESMTP id 7AD8037B860 for ; Wed, 31 May 2000 19:38:32 -0700 (PDT) (envelope-from miklic@ibm.net) Received: from ibm.net ([24.10.140.87]) by mail.rdc1.tx.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <20000601023831.YSXW8081.mail.rdc1.tx.home.com@ibm.net> for ; Wed, 31 May 2000 19:38:31 -0700 Message-ID: <3935CD62.8FA8825E@ibm.net> Date: Wed, 31 May 2000 20:41:38 -0600 From: "Andrew M. Miklic" X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT alpha) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: LWP Support Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG All, I am currently working on OSF1 support for FreeBSD/Alpha, and I found that FreeBSD apparently has no support for any type of LWP mechanism--not only would LWPs make my OSF1 emulation work much easier, but it would also benefit anyone trying to create effective and efficient multi-threaded programs... Does anyone know if there is any work being done on this front, or would anyone be interested in helping me through some of the FreeBSD internals to start my own? Andrew Miklic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 31 20:22:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id BC4CC37B6A7 for ; Wed, 31 May 2000 20:22:37 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e513Mav18009; Wed, 31 May 2000 20:22:36 -0700 (PDT) Date: Wed, 31 May 2000 20:22:36 -0700 From: Alfred Perlstein To: "Andrew M. Miklic" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: LWP Support Message-ID: <20000531202236.A17973@fw.wintelcom.net> References: <3935CD62.8FA8825E@ibm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3935CD62.8FA8825E@ibm.net>; from miklic@ibm.net on Wed, May 31, 2000 at 08:41:38PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Andrew M. Miklic [000531 19:38] wrote: > All, > > I am currently working on OSF1 support for FreeBSD/Alpha, and I > found that FreeBSD apparently has no support for any type of LWP > mechanism--not only would LWPs make my OSF1 emulation work much easier, > but it would also benefit anyone trying to create effective and > efficient multi-threaded programs... > > Does anyone know if there is any work being done on this front, or > would anyone be interested in helping me through some of the FreeBSD > internals to start my own? The linuxthreads port might be a good start. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 31 20:38:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 65C0337B9FB for ; Wed, 31 May 2000 20:38:19 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id UAA29653; Wed, 31 May 2000 20:33:31 -0700 Date: Wed, 31 May 2000 20:36:28 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Terry Lambert Cc: Wes Peters , Chuck Paterson , Doug Rabson , arch@FreeBSD.ORG Subject: Re: Sparc & api for asynchronous task execution (2) In-Reply-To: <200005232330.QAA01056@usr05.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a late response on this (I was away for three weeks), but I can report some historical context on sparc register windows and performance issues with them- in going to the DKI/DDI in the SVr4 port, adding the up-tree/down-tree calls for all the DDI calls cost, initially, a 20% performance hit because we really started overflowing windows substantially more with deeper call stacks than had been there in SunOS 4.0. This made the DKI/DDI extremely unpopular within Sun (for obvious reasons other than rules are annoying). I believe that compilers have gotten substantially better since then so I think that this is much less of an issue than it used to be. There are also some other tricks that can make life easier to manage window spills/unspills. The orig SPARC architecture specified a maximum of 32 windows. I don't believe any chips were done deeper than 8- which certainly was and is too small. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 31 21:10:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id E8FC237BA70 for ; Wed, 31 May 2000 21:10:51 -0700 (PDT) (envelope-from adsharma@sharmas.dhs.org) Received: (from adsharma@localhost) by sharmas.dhs.org (8.9.3/8.9.3) id VAA14386; Wed, 31 May 2000 21:10:38 -0700 Date: Wed, 31 May 2000 21:10:38 -0700 From: Arun Sharma To: "Andrew M. Miklic" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: LWP Support Message-ID: <20000531211038.A14366@sharmas.dhs.org> References: <3935CD62.8FA8825E@ibm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <3935CD62.8FA8825E@ibm.net>; from Andrew M. Miklic on Wed, May 31, 2000 at 08:41:38PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, May 31, 2000 at 08:41:38PM -0600, Andrew M. Miklic wrote: > All, > > I am currently working on OSF1 support for FreeBSD/Alpha, and I > found that FreeBSD apparently has no support for any type of LWP > mechanism--not only would LWPs make my OSF1 emulation work much easier, > but it would also benefit anyone trying to create effective and > efficient multi-threaded programs... > > Does anyone know if there is any work being done on this front, or > would anyone be interested in helping me through some of the FreeBSD > internals to start my own? rfork(2) is the thing that comes closest to an LWP. FreeBSD has kernel support for threads, but no native userland support. The linuxthreads port is the only way of using kernel threads. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 31 22:24:11 2000 Delivered-To: freebsd-arch@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id ACE4337BA9B for ; Wed, 31 May 2000 22:24:06 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (Foolstrustident!@homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id XAA04041; Wed, 31 May 2000 23:23:07 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <3935F40E.761717F5@softweyr.com> Date: Wed, 31 May 2000 23:26:38 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com Cc: Terry Lambert , Chuck Paterson , Doug Rabson , arch@FreeBSD.ORG Subject: Re: Sparc & api for asynchronous task execution (2) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob wrote: > > This is a late response on this (I was away for three weeks), but I can report > some historical context on sparc register windows and performance issues with > them- in going to the DKI/DDI in the SVr4 port, adding the up-tree/down-tree > calls for all the DDI calls cost, initially, a 20% performance hit because we > really started overflowing windows substantially more with deeper call stacks > than had been there in SunOS 4.0. This made the DKI/DDI extremely unpopular > within Sun (for obvious reasons other than rules are annoying). > > I believe that compilers have gotten substantially better since then so I > think that this is much less of an issue than it used to be. There are also > some other tricks that can make life easier to manage window spills/unspills. > > The orig SPARC architecture specified a maximum of 32 windows. I don't believe > any chips were done deeper than 8- which certainly was and is too small. UltraSPARC stacks 8 sets of 32 windows in an almost 3-D manner on the chip, and uses multiple ports into the register file to access registers at different stages of the pipeline. It also has additional scratchpad registers for interrupt contexts, alleviating register window overflows during interrupt processing. Read more at: http://php.iupui.edu/~rsosborn/Scholars_Quest/References/Gathering/Reference_Tools/Bibl/Test-bibl-html.html -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 31 22:33: 0 2000 Delivered-To: freebsd-arch@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 74C5E37BFA9 for ; Wed, 31 May 2000 22:32:56 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (Foolstrustident!@homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id XAA04063; Wed, 31 May 2000 23:30:58 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <3935F5E5.865D3FB@softweyr.com> Date: Wed, 31 May 2000 23:34:29 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Cy Schubert - ITSD Open Systems Group Cc: Poul-Henning Kamp , Neil Blakey-Milner , arch@FreeBSD.ORG Subject: Re: More or Less and GNU References: <200005311330.e4VDU2F09906@cwsys.cwsent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cy Schubert - ITSD Open Systems Group wrote: > > In message <37904.959778395@critter.freebsd.dk>, Poul-Henning Kamp > writes: > > In message <200005311304.e4VD40n08288@cwsys.cwsent.com>, Cy Schubert - ITSD O > > pe > > n Systems Group writes: > > >I've noticed some commits to -current and ports over the last week that > > >indicate that Berkeley more is being replaced by GNU less. Granted > > >less is a better product and I use it myself, my question is about GNU > > >licensing. > > > > Look at; > > > > /usr/src/contrib/less/LICENSE > > > > It contains a 2 clause BSD license... > > Thanks. I should have looked before assuming that it had the GNU > license. It does, it just has a better one too. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 31 23:36:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 6B8E337BA0E for ; Wed, 31 May 2000 23:36:28 -0700 (PDT) (envelope-from jasone@magnesium.net) Received: (qmail 17507 invoked by uid 1142); 1 Jun 2000 06:36:26 -0000 Date: 31 May 2000 23:36:26 -0700 Date: Wed, 31 May 2000 20:20:26 -0700 From: Jason Evans To: "Andrew M. Miklic" Cc: freebsd-arch@freebsd.org Subject: Re: LWP Support Message-ID: <20000531202026.A16569@blitz.canonware.com> References: <3935CD62.8FA8825E@ibm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3935CD62.8FA8825E@ibm.net>; from miklic@ibm.net on Wed, May 31, 2000 at 08:41:38PM -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, May 31, 2000 at 08:41:38PM -0600, Andrew M. Miklic wrote: > I am currently working on OSF1 support for FreeBSD/Alpha, and I > found that FreeBSD apparently has no support for any type of LWP > mechanism--not only would LWPs make my OSF1 emulation work much easier, > but it would also benefit anyone trying to create effective and > efficient multi-threaded programs... > > Does anyone know if there is any work being done on this front, or > would anyone be interested in helping me through some of the FreeBSD > internals to start my own? There was a lengthy discussion last winter on -arch about improving FreeBSD's threads support, and the result of the discussion is that we're pursuing scheduler activations (SAs) rather than LWPs. I'm currently working out the design on paper, and hope to be coding it soon. It is probably possible to create a shim on top of SAs that looks like LWPs, but this isn't something I've given much thought to. One thing at a time. =) Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 1 22:31:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id 02F4737B7EC for ; Thu, 1 Jun 2000 22:31:14 -0700 (PDT) (envelope-from adsharma@sharmas.dhs.org) Received: (from adsharma@localhost) by sharmas.dhs.org (8.9.3/8.9.3) id WAA17489 for arch@freebsd.org; Thu, 1 Jun 2000 22:31:02 -0700 Date: Thu, 1 Jun 2000 22:31:01 -0700 From: Arun Sharma To: arch@freebsd.org Subject: Re: Preemptive kernel on older X86 hardware Message-ID: <20000601223101.A17391@sharmas.dhs.org> References: <200005250208.TAA78220@apollo.backplane.com> <82645.959243483@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <82645.959243483@localhost>; from Jordan K. Hubbard on Thu, May 25, 2000 at 01:31:23AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, May 25, 2000 at 01:31:23AM -0700, Jordan K. Hubbard wrote: > > On intel anyway, subroutine calls are *cheap*, especially compared > > to the overhead of a locked instruction or even an L1 cache miss. > > I don't believe this is true on all the architectures FreeBSD is > anticipated to run on in the "near future", however. And self modifying code also isn't exactly cheap either on that architecture. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 1 22:49:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id 0E7F937B63C for ; Thu, 1 Jun 2000 22:49:14 -0700 (PDT) (envelope-from adsharma@sharmas.dhs.org) Received: (from adsharma@localhost) by sharmas.dhs.org (8.9.3/8.9.3) id WAA17535; Thu, 1 Jun 2000 22:48:59 -0700 Date: Thu, 1 Jun 2000 22:48:59 -0700 From: Arun Sharma To: Mark Blackman Cc: arch@FreeBSD.ORG Subject: NUMA (Was Re: Preemptive kernel on older X86 hardware) Message-ID: <20000601224859.A17524@sharmas.dhs.org> References: <200005301715.LAA27213@berserker.bsdi.com> <20000531172432.A7547@sophos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <20000531172432.A7547@sophos.com>; from Mark Blackman on Wed, May 31, 2000 at 05:24:32PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, May 31, 2000 at 05:24:32PM +0100, Mark Blackman wrote: > On a nearly unrelated note, anybody care to venture > how tough would it be to modify *BSD* to run on a NUMA system > instead of an SMP solution. Most of the SMP optimizations (per CPU data structures to reduce locking) will help NUMA too. Additionally, (a) malloc(9) needs to be rewritten to allocate memory on the local node. (b) page allocation algorithms (vm_page_alloc) need to be rewritten. (c) some amount of process migration and page migration need to be implemented. (d) primitive load balancing (e) APIs to provide hints to the kernel on how to allocate shared memory. (f) kernel text and read only data replication. (g) Page cache replication for read only pages (feasible ?) -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 1 23:50:44 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 6467E37B7B1 for ; Thu, 1 Jun 2000 23:50:41 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id XAA32623; Thu, 1 Jun 2000 23:46:21 -0700 Date: Thu, 1 Jun 2000 23:49:21 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Arun Sharma Cc: Mark Blackman , arch@FreeBSD.ORG Subject: Re: NUMA (Was Re: Preemptive kernel on older X86 hardware) In-Reply-To: <20000601224859.A17524@sharmas.dhs.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > (a) malloc(9) needs to be rewritten to allocate memory on the local node. I'd also like to see malloc have a device component as well so that allocating memory for devices can be made more optimal for devices and their relative bus locations- i.e., like mbuf loanout or public allocators for NICs so that memory constraints for that NIC and bus interconnects. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 2 11:25:50 2000 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 2C80F37BC7B for ; Fri, 2 Jun 2000 11:25:46 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (nobody@relay.nuxi.com [169.237.7.38]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id LAA48814 for ; Fri, 2 Jun 2000 11:25:43 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id LAA85617 for arch@freebsd.org; Fri, 2 Jun 2000 11:25:56 -0700 (PDT) (envelope-from obrien) Date: Fri, 2 Jun 2000 11:25:55 -0700 From: "David O'Brien" To: arch@freebsd.org Subject: Plans to change our debugging format to DWARF2 Message-ID: <20000602112555.A85602@dragon.nuxi.com> Reply-To: obrien@NUXI.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The GDB developers have encourage me to change our native debugging format from STABS to DWARF2 (for ELF binaries). This is your chance to comment before I make my decision. From a GDB person: STABS just wasn't made to do what it's being hacked around to do right now. Fer instance, C++ support in stabs really just isn't there in GDB. The fact that operator overloading works at all in stabs+gdb, is due to a hack. DWARF2 has clear technical superiority over STABS, though STABS has more political clout, and more implementations. The STABS implementation in gcc is more mature than the dwarf2 implementation. In fact, DWARF2 even allows for debugging of frame-pointerless code, though we don't grok the unwind info yet (it's on my list). As you can imagine, C++ in gdb works about 50x better with dwarf2 than with stabs in actuality. Things like inline functions, etc, work properly in DWARF2, and don't in stabs. So, in simple terms, dwarf2 is just much more flexible than stabs. If you need to do C++ at all, i would really go with DWARF2, the more that do, the sooner i don't have to deal with bug reports of bugs that just work when you use DWARF2, and I have to hack around in GDB to make work with STABS. -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 2 13:33:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 971F737B51F for ; Fri, 2 Jun 2000 13:33:17 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA03725; Fri, 2 Jun 2000 16:32:53 -0400 (EDT) Date: Fri, 2 Jun 2000 16:32:53 -0400 (EDT) From: Daniel Eischen To: "David O'Brien" Cc: arch@FreeBSD.ORG Subject: Re: Plans to change our debugging format to DWARF2 In-Reply-To: <20000602112555.A85602@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 2 Jun 2000, David O'Brien wrote: > The GDB developers have encourage me to change our native debugging > format from STABS to DWARF2 (for ELF binaries). This is your chance to > comment before I make my decision. > > From a GDB person: > > STABS just wasn't made to do what it's being hacked around to do > right now. Fer instance, C++ support in stabs really just isn't > there in GDB. The fact that operator overloading works at all in > stabs+gdb, is due to a hack. DWARF2 has clear technical superiority > over STABS, though STABS has more political clout, and more > implementations. The STABS implementation in gcc is more mature than ^^^^^ dwarf2? > the dwarf2 implementation. ^^^^^^ STABS? > In fact, DWARF2 even allows for debugging > of frame-pointerless code, though we don't grok the unwind info yet > (it's on my list). As you can imagine, C++ in gdb works about 50x > better with dwarf2 than with stabs in actuality. Things like inline > functions, etc, work properly in DWARF2, and don't in stabs. So, in > simple terms, dwarf2 is just much more flexible than stabs. If you > need to do C++ at all, i would really go with DWARF2, the more that > do, the sooner i don't have to deal with bug reports of bugs that > just work when you use DWARF2, and I have to hack around in GDB to > make work with STABS. Sounds like a good idea to me. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 2 13:44:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from c1mailgw1.prontomail.com (c1mailgw1.prontomail.com [208.178.29.197]) by hub.freebsd.org (Postfix) with ESMTP id 5247537B6A5 for ; Fri, 2 Jun 2000 13:44:53 -0700 (PDT) (envelope-from giffunip@asme.org) Received: by c1mailgw1.prontomail.com (NPlex 4.5.049) id 39089AB300342735 for arch@freebsd.org; Fri, 2 Jun 2000 13:44:45 -0700 Received: from 200.41.109.149 by SmtpServer for ; Fri, 02 Jun 2000 20:33:09 +0000 Message-ID: <39381E39.5A14B897@asme.org> Date: Fri, 02 Jun 2000 15:51:05 -0500 From: "Pedro F. Giffuni" Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: arch@freebsd.org Subject: Re: Plans to change our debugging format to DWARF2 References: <20000602112555.A85602@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > > The GDB developers have encourage me to change our native debugging > format from STABS to DWARF2 (for ELF binaries). This is your chance to > comment before I make my decision. > I think it's good; it seems like at least Unixware did that move. Here are two links I found in a fast peek at altavista: http://iecc.com/comparch/article/92-05-026 http://www.eagercon.com/dwarf/dwarf2std.htm Hopefully it will also be good for other languages. cheers, Pedro. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 3 7:36:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (Postfix) with ESMTP id 9651E37B545 for ; Sat, 3 Jun 2000 07:36:23 -0700 (PDT) (envelope-from rb@gid.co.uk) Received: (from uucp@localhost) by isbalham.ist.co.uk (8.9.2/8.8.7) with UUCP id PAA78770; Sat, 3 Jun 2000 15:35:38 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from [194.32.164.2] (eccles [194.32.164.2]) by seagoon.gid.co.uk (8.9.3/8.9.3) with ESMTP id PAA62285; Sat, 3 Jun 2000 15:30:52 +0100 (BST) (envelope-from rb@gid.co.uk) X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: <20000602112555.A85602@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 3 Jun 2000 15:30:51 +0100 To: obrien@NUXI.com From: Bob Bishop Subject: Re: Plans to change our debugging format to DWARF2 Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:25 -0700 2/6/00, David O'Brien wrote: >The GDB developers have encourage me to change our native debugging >format from STABS to DWARF2 (for ELF binaries). This is your chance to >comment before I make my decision.[etc] Do it. Apart from anything else, DWARF2 is under active maintenance from a reasonable constituency of interested parties. -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 3 11:25:20 2000 Delivered-To: freebsd-arch@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id B4BDF37BFF0 for ; Sat, 3 Jun 2000 11:25:15 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (Foolstrustident!@homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id MAA11665; Sat, 3 Jun 2000 12:25:08 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <39394E63.A17E7D78@softweyr.com> Date: Sat, 03 Jun 2000 12:28:51 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pedro F. Giffuni" Cc: arch@FreeBSD.ORG Subject: Re: Plans to change our debugging format to DWARF2 References: <20000602112555.A85602@dragon.nuxi.com> <39381E39.5A14B897@asme.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Pedro F. Giffuni" wrote: > > David O'Brien wrote: > > > > The GDB developers have encourage me to change our native debugging > > format from STABS to DWARF2 (for ELF binaries). This is your chance to > > comment before I make my decision. > > > > I think it's good; it seems like at least Unixware did that move. Here > are two links I found in a fast peek at altavista: > http://iecc.com/comparch/article/92-05-026 > http://www.eagercon.com/dwarf/dwarf2std.htm > > Hopefully it will also be good for other languages. I can't see how it would help fortran, but I haven't looked into f90 much yet. I guess that means I'm falling behind. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 3 18:58:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id A60F037C5D0 for ; Sat, 3 Jun 2000 18:58:44 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id SAA00763; Sat, 3 Jun 2000 18:58:43 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id SAA36633; Sat, 3 Jun 2000 18:58:42 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Sat, 3 Jun 2000 18:58:42 -0700 (PDT) Message-Id: <200006040158.SAA36633@vashon.polstra.com> To: obrien@NUXI.com Reply-To: arch@freebsd.org Subject: Re: Plans to change our debugging format to DWARF2 In-Reply-To: <20000602112555.A85602@dragon.nuxi.com> References: <20000602112555.A85602@dragon.nuxi.com> Organization: Polstra & Co., Seattle, WA Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20000602112555.A85602@dragon.nuxi.com>, David O'Brien wrote: > The GDB developers have encourage me to change our native debugging > format from STABS to DWARF2 (for ELF binaries). This is your chance to > comment before I make my decision. Go for it. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message