Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
On 10/10/10 7:09 PM, Devin Teske wrote: On Oct 9, 2010, at 10:25 PM, Julian Elischer wrote: For what it matters, I'v enever found the [ x$foo = x ] construct to be useful. the quoting seems to work for everything I've ever worked on. There have been times where I had scripts which could get errors unless x$foo was used, but it's been more than 10 years since I last hit that situation. Of course, ever since I did hit it, I tend to write my 'test' parameters in ways which avoid the problem. It might have only been when checking if the variable was set to anything. Eg, using: if [ $foo ] ; then instead of: if [ -n $foo ] ; then ... Or it might have been when combining multiple checks in a single 'test' (using -a's, etc). However, I'm not going to try to dream up a pathological example of that right now. I agree... I think that the x syntax came around for when people were using non-quoted syntax... for example... [ x$foo = x ] is still very useful in that it prevents the error when $foo expands to -e. The non-quoted example is dangerous in the case where $foo has multiple words in it. The x does not save you from that problem. I have a 'list_args' script which just lists out the parameters it is called with: # Test=this is a multi-word test # list_args x$Test list_args at 19:22:27 Oct 10: $# = 5 ARG[000] l=005: 'xthis' ARG[001] l=002: 'is' ARG[002] l=001: 'a' ARG[003] l=010: 'multi-word' ARG[004] l=004: 'test' However, enclosing the argument (as the 'x$foo' portion is really just the first argument to the '[' built-in) in quotes: [ $foo = x ] makes it so that the expansion is taken as: [ -n = x ] rather than: [ -n = x ] The former not causing an error, while the latter does. The latter does not cause an error. Try it: # [ -n = x ] ; echo $? 1 # [ -e = no ] ; echo $? 1 # [ -e = -n ] ; echo $? 1 Quite functionally, at a C-level, if you have your array, ... argv[0] = [\0; argv[1] = \-n\\0; /* quoted syntax */ argv[2] = =\0; argv[3] = x\0; and argv[0] = [\0; argv[1] = -n\0; /* non-quoted syntax */ argv[2] = =\0; argv[3] = x\0; You won't see the double-quotes in the C program. The shell processes single and double quotes, and passes the result to the C program which is running. It might be different for built-in functions, but /bin/test would never see the double-quotes if they were used. And since the built-in function has to work the same as standalone function, I doubt the built-in would be any different. # list_args -n list_args at 19:36:15 Oct 10: $# = 1 ARG[000] l=002: '-n' # list_args -n list_args at 19:36:22 Oct 10: $# = 1 ARG[000] l=002: '-n' (note that the single-quotes you see there are printed by the list_args script itself for display purposes). /disclaimer: I think this is the first post that I've made with the new open-source edition of Eudora, and I have no idea if this will be formatted the way I'm expecting it be!/ -- Garance Alistair Drosehn = dro...@rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Institute; Troy, NY; USA ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.
On 10/10/10 8:46 PM, Devin Teske wrote: On Oct 10, 2010, at 4:51 PM, Garance A Drosihn dro...@rpi.edu mailto:dro...@rpi.edu wrote: The latter does not cause an error. Try it: # [ -n = x ] ; echo $? 1 # [ -e = no ] ; echo $? 1 # [ -e = -n ] ; echo $? 1 1 is error. 0 is success. -- Um, yes, true. I know that. What I'm saying is that the command works as you'd want it to work. It does not hit a parsing error. The double-quotes did not change how the command behaved. You deleted the context of what I was replying to when I said the above. Looking at the examples I gave there, it probably would have been clearer if I had typed the exact same command with and without the double-quotes. Eg: On 10/10/10 7:09 PM, Devin Teske wrote: However, enclosing the argument (as the 'x$foo' portion is really just the first argument to the '[' built-in) in quotes: [ $foo = x ] makes it so that the expansion is taken as: [ -n = x ] rather than: [ -n = x ] The former not causing an error, while the latter does. Your second example does not cause an error. Try it: # [ -n = -n ] ; echo $? 0 # [ -n = x ] ; echo $? 1 Compared to the double-quote-less: # [ -n = -n ] ; echo $? 0 # [ -n = x ] ; echo $? 1 -- Garance ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: usinig cvs diff to make a patch
At 2:17 PM -0500 2/3/09, Aryeh M. Friedman wrote: I use a local cvs repo and I have modified a port and which to submit an update for it how do I generate a patch file with cvs (cvs diff seems to give a unusable format)? try: cvs diff -u In my case, i have added the following line to my ~/.cvsrc file: diff -uN (-N means treat absent files as empty) -- Garance Alistair Drosehn= g...@gilead.netel.rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Instituteor dro...@rpi.edu ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Impact of having a large number of open file descriptors
At 12:33 AM +0200 6/3/08, Kris Kennaway wrote: Ivan Voras wrote: Suleiman Souhlal wrote: I have an old patch that makes kqueue monitor every file write on the system and return the inode number in the knote's data field: http://people.freebsd.org/~ssouhlal/testing/kqueue-anyvnode-20050503.diff . I'd think it shouldn't be too hard to make it per-mountpoint.. FWIW, I would love to use this. I have situations where I have huge numbers of files and need to cheaply detect changes so I can resynchronize them to remote machines. I remember a discussion of changes to MacOS10 in Leopard which made it easier to implement features such as Spotlight and TimeMachine. The description starts here, I think: http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/7 the section on file-system events. The idea I thought was interesting was to save the metadata on a directory basis, instead of saving it on the file. So, if file /some/dir/fname was changed, then they'd record that *some* file under /some/dir has changed. So when your userland process comes along later on, it still has to scan all files in that directory to see which file(s) actually changed. But that's a lot less work than scanning all files in the filesystem, and it also means there is much less data that has to be kept track of. I have no idea how easy it would be to implement something similar on FreeBSD, but the strategy seemed like a pretty neat idea. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [OT] Q: what would you choose for a VCS today
At 8:45 AM +0200 1/31/08, Adrian Penisoara wrote: Hi, Side-topic, if you bear with me: if you were to choose again what to use as source revision control system (VCS) from today's offerings, what would you choose to maintain FreeBSD's sources or a side-off project tracking FreeBSD as base that would allow better teams cooperation and easy code merging between projects/branches ? You'll probably get a different answer from each person... :-) As for me, I'd go with subversion. I also believe 'git' might be a very interesting choice, but I haven't used it enough to know how well it works in practice. And I think that's the basic difficulty in trying to answer your question. Very few people have enough experience with all of the available VCS systems to do a comparison. I have worked a lot with RCS and CVS. I've done a little with perforce, but it is so different than CVS that I can't say that I gave it a fair chance. I just thought Oh boy, this is too weird!, and went on to some other project. I don't have enough time to take a real project, and try to make the same set of changes to multiple copies of the repository, to see which VCS *really* does a better job for everything which is needed. One of the guys I know swears that darcs is the best thing ever, and I can see how it would work well for some projects, but I can't imagine it working well for a project such as FreeBSD. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: struct dirent question
At 11:31 AM -0500 8/16/06, Eric Anderson wrote: My point was, that either path you take (if BSD_VISIBLE is defined or not), you end up with d_name having a size of 255 + 1, so what's the point the having it at all? To make it clear that d_name is tied to the exact value of MAXNAMLEN (just in case that value ever changes), and it does not just happen to be 255+1 bytes for some reason that is completely unrelated to MAXNAMLEN. So if some programmer is working with the d_name variable, and *if* they actually look at this include file, then they'll immediately realize that any checks that they make should use MAXNAMLEN, and not hard-code in the 255 value. That's my 2-cents worth, at least... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/99979: Get Ready for Kernel Module in C++
At 7:03 PM -0400 7/11/06, Mike Meyer wrote: In [EMAIL PROTECTED], Rick C. Petty [EMAIL PROTECTED] typed: On Wed, Jul 12, 2006 at 02:25:21AM +0800, [EMAIL PROTECTED] wrote: Good packages for various APIs are much easier to learn/debug than those original APIs. What makes you say that C++ would provide a good API? Good point. About the only thing C++ has going for it as an OO language is popularity. If the goal is just to provide better API in the kernel, then there are certainly better languages to add. D comes to mind. I'd much rather write D than C++ - but that's got more to do with C++ than D, as it's true for most substitutes for D. But D is OO - done much better than C++ - and has a front end available for GCC. This would be an interesting idea. I haven't used D for anything myself, but some friends of mine have and think that it is quite good. They say the available libraries are still a little thin in what they implement, but maybe it'd be better to start with some kind of thin environment, and see how that works out. I guess that wouldn't help out much with supporting IOKit, though, if IOKit is already written using C++. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvi for serious hacking
At 1:25 PM -0600 10/17/05, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Gary Kline [EMAIL PROTECTED] writes: : vi was the first screen/cursor-based editor in computer : history. Are you sure about this? I was using screen oriented editors over a 1200 baud dialup line in 1977 on a PDP-11 running RSTS/E on a Behive BH-100. Seems like one year from vi to being deployed at Berkeley to a completely different video editor being deployed on a completely different os in the schools that I used this in seems fast. So I did some digging. vi started in about 1976[1] as a project that grew out of the frustration taht a 200 line Pascal program was too big for the system to handle. These are based on recollections of Bill Joy in 1984. It appears that starting in 1972 Carl Mikkelson added screen editing features to TECO[2]. In 1974 Richard Stallman added macros to TECO. I don't know if Carl's work was the first, but it pre-dates the vi efforts. Other editors may have influanced Carl. Who knows. I arrived in RPI in 1975. In December of 1975, we were just trying out a mainframe timesharing system called Michigan Terminal System, or MTS, from the university of Michigan. The editor was called 'edit', and was a Command Language Subsystem (CLS) in MTS. That meant it had a command language of it's one. One of the sub-commands in edit was 'visual', for visual mode. It only worked on IBM 3270-style terminals, but it was screen-based and cursor-based. The editor would put a bunch of fields up on the screen, some of which you could modify and some you couldn't. The text of your file was in the fields you could type over. Once you finished with whatever changes you wanted to make on that screen, you would hit one of 15 or 20 interrupt-generating keys on the 3270 terminal (12 of which were programmable function keys, in a keypad with a layout similar to the numeric keypad on current keyboards). The 3270 terminal would then tell the mainframe which fields on the screen had been modified, and what those modifications were. The mainframe would update the file based on that info. I *THINK* the guy who wrote that was ... Bill Joy -- as a student at UofM. I can't find any confirmation of that, though. The closest I can come is the web page at http://www.jefallbright.net/node/3218 , which is an article written by Bill. In it he mentions: By 1967, MTS was up and running on the newly arrived 360/67, supporting 30 to 40 simultaneous users. ... By the time I arrived as an undergraduate at the University of Michigan in 1971, MTS and Merit were successful and stable systems. By that point, a multiprocessor system running MTS could support a hundred simultaneous interactive users, ... But he doesn't happen to mention anything about editors or visual mode. My memory of his connection to MTS's visual-mode could very well be wrong, since I didn't come along until after visual-mode already existed. I just remember his name coming up in later discussions. However, I also think there was someone named Victor who was part of the story of 3270 support in MTS. And Dave Twyver at University of British Columbia was the guy who wrote the 3270 DSR (Device Support Routine), as mentioned on the page at: http://mtswiki.westwood-tech.com/mtswiki-index.php/Dave%20Twyver In any case, I *am* sure that MTS had a visual editor in December of 1975, which puts before vi if vi started in 1976. Unfortunately, all of the documentation of MTS lived in the EBCDIC world, and pretty much disappeared when MTS did (in the late 1990's). -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Include files that depend on include files
At 12:06 PM +0200 8/10/05, Dirk GOUDERS wrote: To get around this in user-space, we do things like create /usr/include/sys/_types.h And then our include files include *that* file, and do not include the standard sys/types.h. This sys/_types.h file, in turn, does not define any of the actual symbols. Let's say that some include file needs to know what typedef for 'off_t' is. The sys/_types.h file defines __off_t, and then the include file which needs off_t will do something like: #include sys/_types.h #ifndef _OFF_T_DECLARED typedef __off_t off_t; #define _OFF_T_DECLARED #endif Thus, it has only defined the one name it actually needs, instead of defining all of the standard symbols in the real sys/types.h. Can you point me to a real-life example where such a mechanism is used? I'd like to have a closer look at it. The above lines came from FreeBSD's /usr/include/sys/stat.h Note that it includes sys/_types.h and not sys/types.h There are many other examples in the FreeBSD system includes, at least once you get to the 5.x-series of FreeBSD. I don't remember if we were doing that in the 4.x-series. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Include files that depend on include files
At 12:22 AM +0200 8/10/05, Dirk GOUDERS wrote: This is intentational. We try to avoid having headers bring in more then absolutly required when included. I'm not sure what your second question means. With my second question I wanted to ask if this intention is only for kernel level code or a general one. I am asking this, because somewhen in a project that I was not actually participating in I heard or read a rule that roughly said: all include files have to include all files they depend on and compile cleanly, but that project was on a user space program. It gets a little tricky. POSIX rules for include files include various requirements against namespace pollution. So, if you bring in one particular include file, then you're supposed to be confident that it will only define the symbols that you expect from that one file. And yet you will need to have that include file reference some values which (according to standards) are defined by some other standard include file. You need one or two symbols, but you're not allowed to define any of the other symbols. To get around this in user-space, we do things like create /usr/include/sys/_types.h And then our include files include *that* file, and do not include the standard sys/types.h. This sys/_types.h file, in turn, does not define any of the actual symbols. Let's say that some include file needs to know what typedef for 'off_t' is. The sys/_types.h file defines __off_t, and then the include file which needs off_t will do something like: #include sys/_types.h #ifndef _OFF_T_DECLARED typedef __off_t off_t; #define _OFF_T_DECLARED #endif Thus, it has only defined the one name it actually needs, instead of defining all of the standard symbols in the real sys/types.h. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unitialized memory is all zeros...why not garbage instead?
At 3:40 PM -0700 6/10/05, Mike Hunter wrote: Hey everybody, I have a feeling that I'm missing something really obvious, but I'm having trouble understanding why the following program: Never prints anything but 0's. Kernel generally clears out memory in the background. See also the man page for 'malloc', which will describe some options that you can set by creating an appropriate symlink at /etc/malloc.conf. In particular, the -J flag. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: req: New feature to rm? Remove file by the inode number
At 2:19 PM +0300 5/5/05, Erik Udo wrote: I couldn't find a way to remove files that had scandic/non-printable letters, then i remembered ls showed inode number of the file. Is it possible to remove the file by the inode number? It would be a useful feature :) It would be a bad feature, at least for the problem you are trying to solve. You are trying to remove one specific filename from one specific directory. It is possible to link multiple filenames to the exact same file (inode). If a file has multiple links to it, then you would want to remove only the filename you're looking at, and not all filenames in the filesystem which might have the same inode. Other solutions, with 'find' or 'rm -i ./*', are more correct for the situation you are looking at. Note that if a file only has *some* unprintable characters, and also has some standard characters, then you can use pattern-matching to reduce how many fines would be matched by 'rm -i'. Something like: rm -i ./*blah* I have been in similar situations to what you're describing, and I've never had to do more than pick a reasonable filename pattern and combine it with -i (-i for interactive, so it prompts you for each file before removing it). -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel killing processes when out of swap
At 6:46 PM +0200 4/12/05, Dag-Erling Smørgrav wrote: Steven Hartland [EMAIL PROTECTED] writes: Thanks for the feedback seems very strange that sshd was the first thing the kernel killed off; so unless it was actually at fault ( would be very strange ) it would have been one of the smallest not largest processes. The box has runs several 200M+ process and more 100M+ where as sshd is usually 6M. So this leads me to the questions: 1. Any know issues ssh which could make it eat memory? 2. Is there possibly a bug with the large process detection? There is no large process detection. The first process that tries to fault in a new page after the system runs out of swap gets killed. From time-to-time, we talk about implementing some form of SIGDANGER, similar to what AIX has. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: organization
At 7:41 AM -0800 3/29/05, mohamed aslan wrote: guys this is not a flame war but the linux way in arranging the source file is really better than freebsd way, it's a fact. however it's easy to rearrange it in 1 min as someone said before. but i mean this step should be done from the core team. for example all fs has to go in a subdir called fs arch specific file should go in subdir called arch/(arch name) and so on . One thing to watch out for is the mess this would cause in the CVS repository. CVS does not track file moves, so if we move a lot of things around then we just end up with them in *both* the old and the new locations. I certainly believe the tree could be organized better than it is, but the benefits from reorganizing are just not worth the time and effort it would take (*), and the mess it would make out of the CVS repository. (* - 99% of the time and effort would be in getting everyone to *agree* on the best layout...) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARG_MAX increase
At 2:11 PM -0500 2/23/05, Garance A Drosihn wrote: At 10:46 AM +0100 2/23/05, Marco van de Voort wrote: I saw ARG_MAX was increased in 6.0. Recently I noticed that the lang/fpc-devel port currently hits the old limit in certain (though rare) cases), and this is annoying. (some testing revealed that half the increase of 6.0 to 131k params is also ok) Any chance ARG_MAX will be upped in -STABLE too? For this specific example, it would be better to fix the port. I should add to this that I have no objection to seeing it raised in 5.x-stable. I'm just saying that even if we do raise it right now, there are a lot of users who will not be helped if the value is only changed in 5.x-stable. I (personally) would rather not see it changed so close to 5.4-release, but it might make sense to increase it in -stable shortly after 5.4-release. I have no opinion on what value it should be changed to, though, if we do increase it. I do not work in that part of the system, so I don't know all the pros and cons that would be involved. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARG_MAX increase
At 10:46 AM +0100 2/23/05, Marco van de Voort wrote: I saw ARG_MAX was increased in 6.0. Recently I noticed that the lang/fpc-devel port currently hits the old limit in certain (though rare) cases), and this is annoying. (some testing revealed that half the increase of 6.0 to 131k params is also ok) Any chance ARG_MAX will be upped in -STABLE too? For this specific example, it would be better to fix the port. The port has to work on many releases in addition to 5.x-stable and 6.x-current. We can't change ARG_MAX in all of those releases to fix the port. We certainly can't change it in 5.3-RELEASE (because that's sitting on CD's), and we probably aren't going to change it in 5.3-ERRATA (the minimal change security branch, which many people run on production servers), and it's even less likely that we'll change it in 4.x-stable. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bin/76089: The -n option in /usr/bin/w is broken
At 5:16 PM +1100 2/14/05, Peter Jeremy wrote: On Sun, 2005-Feb-13 19:50:44 +0300, Sergey Matveychuk wrote: IMHO to be more robust, we should make utmp to hold an IP address instead of a hostname and change all applications that use it. As bonus it will fix a delay on login when resolving does not work. And last(1) will show more useful IP address instead of changable hostname. Depending on the environment, the IP address may be more changeable than the hostname. Definitely, in a DHCP or dialup environment, you can't rely on the IP address at any time other than during the session. There is little (if any) benefit in logging the IP address instead of the hostname. Actually, it would be nice to log both. That's what I have done for some printer-related statistics (not sure if I did that in FreeBSD, but I do that for production use at RPI). -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenCVS
At 8:58 PM +0100 12/7/04, Miguel Mendez wrote: Hi hackers, I've seen the OpenBSD guys have come up with a BSD-licensed CVS[1] that should be focused on security as well as features. Is there any chance that this could make it into FreeBSD's tree as well? [1] http://www.openbsd.org/opencvs/ From that web page: OpenCVS released soon Certainly FreeBSD will be interested in seeing how well OpenCVS works, but we like to wait until the code is released before we make any claims about when it will show up in the base system of FreeBSD. I know it's been slash-dotted and all, but it only seems fair that we wait for the actual source-code from the people who are apparently still working on it... That said, we obviously prefer code with a BSD license. So it is reasonable to think that some form of OpenCVS might eventually show up in FreeBSD, the same way that OpenSSH and PF have. But there is no way we can guess at a timetable for that now, when even OpenBSD has not shipped a release with OpenCVS yet! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AoE for FreeBSD
At 3:36 PM -0500 11/10/04, Sam Hopkins wrote: Hello all, Just a quick note to mention that I've added AoE support to FreeBSD 4.10, 5.3, and 6.0. Patches are available at http://www.coraid.com/support/freebsd. If anyone knows where else I could announce this, I'd appreciate it. This looks interesting. Will this support be available for multiple hardware architectures? (sparc64, amd64 and PPC would be the ones I am the most interested in after i386) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
At 8:57 PM +0300 10/2/04, Giorgos Keramidas wrote: On 2004-10-02 21:23, Lee Harr [EMAIL PROTECTED] wrote: John Beck, who works for Sun, has posted an entry in his blog yesterday about rm -fr / protection, which I liked a lot: http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection His idea was remarkably simple, so I went ahead and wrote this patch for rm(1) of FreeBSD: How about: chflags sunlnk / ? Setting sunlink on / will only protect the / directory, not its descendants, so you don't gain much. We could add a new flag srunlnk, or maybe even srm-r. The rm command will always have to stat() the file it is given (just to see if it is a directory), so it could check to see if this flag is turned on. If it is turned on, then 'rm' could refuse to honor any '-rf' request on that directory. I like the idea of *some* kind of protection for rm -rf /, but I think it would be better as something more generally useful than protecting against that one single case. While I have typed in a few dozen disastrous rm -rf commands, I have never actually typed in rm -rf /, so this particular seat belt would never have done me any good. By tieing the feature to a settable flag, then I would have the option to protect to other directories (if I wanted to add such protection). -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to clean out old files after 'make world'?
At 10:23 PM +0300 7/20/04, Stas D.Myasnikov wrote: ... I had thought that install script removes all unneeded files, but it don't. How can I clean out this old binaries, configs, etc?.. Is there any automatic way to do this? You can: make cleanworld which does a fairly decent job of getting rid of all the old files in your build area (e.g., in /usr/obj/usr/src). However, I am not sure if you are asking for more than that. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
At 10:48 AM +1000 6/22/04, Greg Black wrote: The output of ls has never been good for reproduceable output for identical data. It frequently leads to gigantic diffs in periodic reports which makes them useless, as far as I can tell. Take the following case: Hmm. I never thought much about that before. Perhaps we should use the output from the `stat' command for all of these tests in the periodic scripts. That way we could pick an exact format. Or maybe those scripts should take advantage of: LS_COLWIDTHS: If this variable is set, it is considered to be a colon- delimited list of minimum column widths. Unreasonable and insufficient widths are ignored (thus zero signifies a dynamically sized column). Not all columns have changeable widths. The fields are, in order: inode, block count, number of links, user name, group name, flags, file size, file name. Those might make the periodic checks more useful. Which scripts have this problem? In a very quick check, I only noticed an `ls' command in security/100.chksetuid. Anything else? Note that I am not volunteering to do the work, though... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -lthr vs. -pthread
At 4:14 AM +0200 6/20/04, Cyrille Lefevre wrote: is it normal that the selected process is the last forked thread and not the thread owner (father) ? I committed the changes, so people can try this if they want. Example: (48) ps -HO lwp,nlwp PIDLWP NLWP TT STAT TIME COMMAND 1870 18701 ?? SL 0:00.13 sshd: [EMAIL PROTECTED] (sshd) 1871 18711 p3 SLs0:00.09 -bash (bash) 2535 126 p3 SL+0:00.00 ./cyr-thread 2535 116 p3 SL+0:00.00 ./cyr-thread 2535 146 p3 SL+0:00.00 ./cyr-thread 2535 25356 p3 SL+0:00.00 ./cyr-thread 2535 106 p3 SL+0:00.00 ./cyr-thread 2535 136 p3 SL+0:00.00 ./cyr-thread (49) ps -O lwp,nlwp PIDLWP NLWP TT STAT TIME COMMAND 1870 18701 ?? S 0:00.13 sshd: [EMAIL PROTECTED] (sshd) 1871 18711 p3 Ss 0:00.09 -bash (bash) 2535 146 p3 S+ 0:00.00 ./cyr-thread When the -H is not requested, why does process 2535 show up as thread-ID #14 instead of #2535? Is that something that we need to change when copying info into kproc_info ? Or is that perfectly reasonable? I have not worked with threaded apps, so I am not sure what people would be expecting here. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug? - change it.
At 6:50 PM +0100 6/19/04, Scott Mitchell wrote: Is this intended behaviour? If so, the documentation is wrong. Otherwise, the attached patch produces the expected output. I can commit it if there are no objections. Your patch looks like a reasonable change to me. By definition, there can be no one which *depends* on the present behavior in this situation, because the present behavior is not consistent. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! KSE needs more attention
At 9:37 AM -0600 6/7/04, Scott Long wrote: Garance A Drosihn wrote: I think you have to officially demote it, with emphasis on the point that demotion is not a terminal condition. Then, if some developer(s) show up and implement all the missing pieces, we can happily announce it back in tier 1. But for now, say that it *IS* demoted. Not that you're advocating that we think about maybe demoting it in the future unless someone offers to start looking into the missing pieces. One thing to note is that whatever platforms get dropped from tier-1 status will have a high probablility of not getting updated with the upcoming binutils/gcc/gdb update that is coming. If that is the case, then you can not say demotion is not a terminal condition. That sounds pretty terminal to me. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! KSE needs more attention
At 3:46 PM -0600 6/6/04, Scott Long wrote: At this point, I'm going to advocate that Alpha be dropped from Tier-1 status for 5.3 and 5-STABLE and no longer be a blocking item for releases. ... As I said back then, demotion is not a terminal condition, and I would be thrilled if someone comes forward in the future and brings the platform back up to date. I think you have to officially demote it, with emphasis on the point that demotion is not a terminal condition. Then, if some developer(s) show up and implement all the missing pieces, we can happily announce it back in tier 1. But for now, say that it *IS* demoted. Not that you're advocating that we think about maybe demoting it in the future unless someone offers to start looking into the missing pieces. At the moment, it probably also makes sense to demote sparc64, even though I own one of those. Not that we have anything against it, but as a practical matter we haven't hit critical mass on it just yet. Since I am interested in sparc64, I can take that as a goal to help make it a tier-1 platform by 5.4-release... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Third RFC on on pkg-data ideas for ports
[this is BCC'ed to -hackers and -arch just so everyone has a chance to see it, but I expect the bulk of the discussion should take place on the freebsd-ports mailing list] Well, Darren and I have done more work on my pkg-data ideas, but we're also getting closer to the time where Darren will be busy with his own full-time job, at which point the progress on this will be much slower. So, I'd like to show some of what we've been working on, make a third proposal, and see if this one is interesting enough for us to pursue. If not, then I'll probably just update my web pages with my thoughts so far, and then put this whole idea on a back-burner. [and if you thought progress was slow before, imagine how slow it will be when moved to a back-burner!] In the last go-round, someone pointed out that it could be helpful just to have a better idea of what the ports-collection really *is*. So we took some time to write a script which goes through a ports collection and gathers some statistics what files exist (on a per-port basis), and how much room they take up. I'll post some results of that script as a follow-up to this message. (that reply will only go to freebsd-ports...). So, hopefully that information will be of some interest even if we never do anything with the pkg-data ideas. Someone else (whose name I also forget) said something which focused my attention a bit more on patch-files per se, and how they really aren't the same as the other files I'm trying to collapse into pkg-data. Also, I haven't gotten quite as far along with figuring out what to do with pkg-descr files, so (in the interests of time), I think I'll leave those alone for this proposal. We've worked on some other ideas too, but those aren't far enough along yet. So I'll just write them up as future work (when I update the web pages...). The third proposal is basically: a) move most standard files into a new pkg-data file, as described in previous proposals, except for pkg-descr and patch files. b) create a new directory at the root directory of the ports collection. That directory would be called Patches, and inside would be a directory for each category. Inside each Patches/category directory would be a single-file for each port in that category, where that single-file would have all the ports-collection patches for the matching port. c) [minor] in the pkg-data section for distinfo, I'd like to change the format for each file from, eg: MD5 (bash-2.05b.tar.gz) = 5238251b4926d778dfe162f6ce729733 SIZE (bash-2.05b.tar.gz) = 1956216 to 5238251b4926d778dfe162f6ce729733 1956216 bash-2.05b.tar.gz So it collapses most standard files into the pkg-data file, and collapses the patch-related files for a given port into files such as: ports/Patches/shells/patches-bash2. This will not result in as dramatic a drop in inodes, but it has the nice side-effect that Patches are separated from all the other files. Thus, end-users could 'cvsup refuse' the patches for categories that they do not care about, and it would not break operations which work on the entire ports collection (such as `make index'). Our current transform script doesn't do part 'c' yet, but I thought it would be interesting to note the result of 'b': (63) du -sk pd-new/ports pd-new/ports/Patches 190944 pd-new/ports 28414 pd-new/ports/Patches 162530 == ports without the Patches And to compare the present ports collection to a transformed ports collection, the result would look like: 1K-blocks Inodes Used Used 23874279154pd-orig/ports 19094449321pd-new/ports 20% 37% = reduction So, should we pursue any of this? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory Leak
At 2:45 PM +0930 5/23/04, Daniel O'Connor wrote: There is valgrind.. http://www.rabson.org/#valgrind I thought it was in ports but I can't see it. ___ Note the separate message: Date: Sat, 22 May 2004 21:46:32 +0200 From: Simon Barner [EMAIL PROTECTED] To: Cole [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Looking for a ports committer for valgrind (Re: Memory Leak) I just wanted to know what programs any of you have used to track down a memory leak in your programs? this reminds me of something... :-/ I created a port for Doug Rabson's FreeBSD port[1] of valgrind [2]. He considered my work ready for the ports tree, but he also said that that he doesn't do any ports commits these days. So, could somebody please have a look at the ports (there is a stable and a development version of valgrind) to be found at [3]? If they get committed, PR ports/65585 can be closed as well (also approved by Doug). It's a pity that I forgot that excellent memory debugging tool, most notably because all the work has already been done, and the ports were only rotting around. :-( Cole, in order two answer your question at least a little bit: valgrind is great at detecting memory leaks and much more, e.g. out-of-bound array access, ... Simon [1] http://www.rabson.org/#valgrind [2] http://valgrind.kde.org/ [3] http://home.leo.org/~barner/freebsd/valgrind/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to flush out cache.?
At 12:23 PM -0700 4/21/04, Julian Elischer wrote: Ok so I have an application where I need to reread a file I have just written to ensure that it went to disk correctly.. Other than reading a few GB of data, is there a way to flush out the cache copy of a file I've written? possibilities include: a file flag saying don't keep a copy after it's written to disk? a syscall discard_cached_blocks(fd); ? any other suggestions? julian (BTW this would be for 4.x initially) Hmm. That means you couldn't use a 'snapshot' to force the issue, right? If you *could* use snapshots, you could close the file, snapshot the partition, mount the snapshot, and read the file from it's copy in the snapshot-filesystem. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Second RFC on pkg-data idea for ports
[this is BCC'ed to -hackers and -arch just so everyone has a chance to see it, but I expect the bulk of the discussion should take place on the freebsd-ports mailing list] Back in January I send out a long-ish email asking for feedback on some ideas I had for the ports-collection. I received a fair number of comments, and have finally re-organized my ideas into a few web pages. Hopefully these will make more sense. Initially I had written the ideas up as a bunch of Wiki pages, but the machine holding that Wiki died, taking with it all the pages I had written... I have not proof-read the web pages, so there's probably some spelling mistakes and odd sentences on them. Apologies for that, but I wanted to get *something* sent out this week. This project has been blocked due to a lack of time on my part, and I want to get it moving again... The basic idea is to collapse many of the separate files for a port into a single pkg-data file. The web pages explain why I think this might be worth doing. Please check them out at: http://people.freebsd.org/~gad/PkgData/ Some of the work for this has been done, mainly just to see how well it might work out. The project is still probably more work than Darren and I can finish, so we might limit ourselves to a subset of the idea. For instance, we might start out by just collapsing the distinfo, pkg-plist, and files/patches-* files into a pkg-data file, and leave the other files for some later project. What I'd like is some idea of whether this project is worth pursuing. If not, then Darren and I will concentrate on some other, less disruptive project. If people like the general idea of this project, then we'll see how much of we can do. If we have some of the details wrong, then let us know what we need to change or where we need to look for more information. I know that I am not a full-fledged expert in every facet of the ports collection, and I am not looking to ram some ideas down everyone's throat. I just think that some change like this one could be useful for the ports collection, and I'm trying to come up with something that everyone sees as useful. If this project does not seem like it would be worth the effort, then that will be perfectly okay too. Please let me know what you think. Also, please read the web pages before responding. It took me a fair amount of time to write the web pages that are there (as lame as they are...), and I'd rather not have to retype all of that into a long series of disjointed messages... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fundraising for FreeBSD development.
At 5:18 PM -0400 4/8/04, John Von Essen wrote: Hi, Have a few questions for you. Would the fund raising be handled through FreeBSD or direct to you? He has answered that. Funding direct to PHK. Please READ the web page that you quoted from his original message: http://people.freebsd.org/~phk/funding.html Are you taking pledges now? I would assume you would gather pledges over the next month to see if can get the USD16500, if you do, then the pledges become real donations, if you don't, then the pledges become null. He has answered that. Pledges are not money. Pledges are wishes. It is a bad idea to bet your family's financial health and your mortgage on the other people's wish to contribute, even if those wishes are well-intended. This is particularly true if that group of well-wishers include a number of people that you have never dealt with before. I can tell you from my own personal experience that many people will promise you money to do something, and then after you do it they'll have a million excuses. Oh, my car broke down, poor little old me. I guess *you* will have to do without that money that I had promised *you*, because *my* car broke down. Believe me, they'll make it sound like you're supposed to apologize to them for the bad luck that they have had. If the fund raising is connected with FreeBSD, could people who donate larger amounts get some form of acknowledgement on the FreeBSD site? This would give an incentive for vendors who sell products that rely or use FreeBSD to donate larger amounts. This has already been discussed in the thread. I'm sure that various things could be arranged for any vendor who really puts up some money to help fund Poul-Henning's work on the specific project he is proposing to do. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
At 10:22 AM -1000 3/21/04, Clifton Royston wrote: Date: Sat, 20 Mar 2004 From: Garance A Drosihn So, by adding one call to strcmp() to check for a : string, I end up with /bin/ps (the stripped-object-file) which has grown by 12.6% !! This is for a program which is almost 2500 lines spread out over 5 '.c'-files. How is that possible? What am I missing here? If it happens that strcmp was not previously being referenced at all, absent this one line, then of course this change will pull in the strcmp routine. Now while strcmp itself is not ... I forgot to include a significant part of this puzzle. The same ps.c file already had two calls to strcmp() in it: ps.c: if (strcmp(elem, co) == 0) ps.c: if (strcmp(elemcopy, :) == 0) ps.c: if (strcmp(vent-var-name, v-name) == 0) There was no strcmp() in the subroutine that I added it to, but I would assume that those other references would have already pulled in the routine. This may also be true even if gcc is partially inlining it. gcc may be pulling in a big clump of its own internal support routines in that case, ... but would it inline it's own routines multiple times in the same source file? Again, differencing the symbol table should give you some idea. Well, I was hoping someone would have already seen this before, but I guess I will need to do some more checking if I'm going to get a better idea of what is going on. I'll put it on my list of things to look at when I have some spare time... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adventures with gcc: code vs object-code size
At 2:52 PM -0800 3/21/04, Kip Macy wrote: The heuristics vary from platform to platform - what does objdump -d show? Based on what I see from that, the 'ps.o' which has the extra strcmp is about 40 bytes larger than the one without it. And now that you mention it, doing a plain 'ls -l' of ps.o shows that it is only 40 bytes larger. It's when you combine that file with the other *.o files, and strip it, that the final result ends up 3940 bytes larger. So maybe this has something to do with how linking is done for ELF modules. Unfortunately, I need to be concentrating on something else right now... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Adventures with gcc: code vs object-code size
At 7:35 PM -0500 3/21/04, Don Bowman wrote: From: Garance A Drosihn [mailto:[EMAIL PROTECTED] So maybe this has something to do with how linking is done for ELF modules. Unfortunately, I need to be concentrating on something else right now... It's not just bumping you up another module 4K pages? The linker aligns text, data, bss, rodata, etc. (65) ls -l /bin/ps* -r-xr-xr-x 1 root wheel 27100 Mar 20 14:29 /bin/ps -r-xr-xr-x 1 root wheel 27296 Mar 21 18:21 /bin/ps-sanscmp -r-xr-xr-x 1 root wheel 31204 Mar 21 19:46 /bin/ps-withcmp The first one is the `ps' before all of my recent changes, the second is all of the changes except for that strcmp(), and the third adds the strcmp. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Adventures with gcc: code vs object-code size
I have written a fairly major set of changes to the `ps' command,
which is available as:
http://people.freebsd.org/~gad/ps-susv3.diff
Debate/discussion about the changes themselves actual changes should
be going on in the freebsd-standards mailing list. So for purposes
of this mailing list, please ignore most of that.
But while doing it, I was somewhat obsessed about making sure that
my changes wouldn't cause a dramatic increase in the size of the
executable for `ps'. Due to that, I tripped over one example of
code vs object-code produced which makes no sense to me. So,
consider just this section of the update (with some reformatting
so it is easy to see the code):
char elemcopy[PATH_MAX];
...do stuff...
#if !defined(ADD_PS_LISTRESET)
inf-addelem(inf, elemcopy);
#else
/*
* We now have a single element. Add it to the
* list, unless the element is :. In that case,
* reset the list so previous entries are ignored.
*/
if (strcmp(elemcopy, :) == 0)
inf-count = 0;
else
inf-addelem(inf, elemcopy);
#endif
Now, here is what I noticed:
* XXX - Adding this check increases the total size of `ps' by
* 3940 bytes on i386! That's 12% of the entire program!
* { using gcc (GCC) 3.3.3 [FreeBSD] 20031106 }
*
* When compiling for sparc, adding this option causes NO
* change in the size of the `ps' executable. And on alpha,
* adding this option adds only 8 bytes to the executable.
So, by adding one call to strcmp() to check for a : string, I end
up with /bin/ps (the stripped-object-file) which has grown by 12.6% !!
This is for a program which is almost 2500 lines spread out over
5 '.c'-files. How is that possible? What am I missing here?
I am not a compilier guru, so I suspect it would take me hours to
pin this down. I don't want to do that, so I'm wondering if anyone
understands how such a minor code-change can POSSIBLY cause such a
huge change in resulting object file... I also wonder if this same
issue pops up in other programs, too.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Style(9) and portability
At 12:18 PM -0800 3/6/04, Tim Kientzle wrote: ... I've been scratching my head over how to deal with the version ID code that is supposed to apear as the first two lines of any FreeBSD source file: #include sys/cdefs.h __FBSDID($FreeBSD$); Clearly, I cannot reasonably assume that all platforms define a __FBSDID macro in sys/cdefs.h. Really, you can't even assume that all platforms will *have* a sys/cdefs.h The second option deals with the issue by pushing it onto a header that encapsulates platform-specific definitions. In particular, the local platform.h header can include sys/cdefs.h on FreeBSD and provide an alternative definition of __FBSDID on other platforms. The drawback is, of course, the requirement for a new local header file to wrap platform-specific decisions: 2) #include platform.h /* Platform-specific defines */ __FBSDID($FreeBSD$); This is basically the tactic that I went with for everything under lpr. That works reasonably well for lpr, but I don't know if it makes sense for everything: #include lp.cdefs.h /* A cross-platform version of sys/cdefs.h */ I intentionally have the comment about sys/defs.h, in case someone comes along later and scans for that string... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADSUP: Commits Planned for 64-bit time_t on sparc64
[this is being BCC'ed to -arch and -hackers just to make sure that everyone is aware of this before changes are committed, but I expect all of the discussion to happen on -current] Sparc64 users (including me) have said that we'd like the sparc64 port to be running with a 64-bit time_t before we make a stable branch for the 5.x-series. I have been working on a procedure that can be used to safely perform this very incompatible change. I think I finally have that pretty much ready-to-go. I will therefore make the bold claim that I plan to take the files you can find at: http://people.freebsd.org/~gad/time-64/UPDATING.64BTT http://people.freebsd.org/~gad/time-64/installworld_oldk http://people.freebsd.org/~gad/time-64/installworld_newk and I plan to commit them to /usr/src, on Wed March 3rd. This does not actually change anything, but it tells adventurous sparc64 users that we're officially on the way to making this change, so they can try upgrades to 64-bTT (64-bit time_t). These files are only going to be in the base system long enough to help sparc64 users through the transition. I am very interested in any show-stopper problems in what I have written. My hope is that these files will disappear shortly after 5.3-release, though, so I don't want to spend much time polishing the scripts up when it comes to style issues. I'm still interested in hearing about them, but I may not be in a rush to do anything about style issues. Assuming that no one runs into a show-stopper problem, I plan to commit the change to /usr/src/sys/sparc64/include/_types.h that switches to 64-bTT for sparc. /usr/src/UPDATING will also need to have an entry added, but that entry will just point to the /usr/src/UPDATING.64bTT file. I plan to commit this (or have Warner commit the change to UPDATING?) on Wednesday March 10th. All of these changes will cause zero changes for people who are running on other hardware platforms. Only sparc64 users have to lay awake in terror of what this change might do to them. I should note that it *has* been working fine for me... :-) Also, about a dozen other sparc64 users have used these files to make a successful transition, with very few problems reported. As for me, I expect that my real-work job is going to get much busier by March 15th. If this 64-bTT change is not committed at that point, then some other developer will have to lead the charge for making the change. And, personally, I think we are already awfully close to the time for 5.3-release, and we can not afford to get much closer to it before making this change. So if we can not make this change by March 15th (at the latest), then I think we will have to put it off until 6.0. In fact, if I had a fix for the dhclient issue I would prefer to move both of the planned commits up by a week. I know this could be improved upon if I had more time to work on it, but this is basically the best I could do with the time I had. If my main job had something to do with FreeBSD, then I would have some way to justify spending more time working on issues like this... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding 'realclean' target to /usr/src/Makefile
At 10:19 AM -0700 2/15/04, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Garance A Drosihn [EMAIL PROTECTED] writes:
: realclean :
: rm -Rf ${.OBJDIR}/*
I'd make that be more like:
realclean :
@chflags -R 0 ${.OBJDIR}/*
@rm -Rf ${.OBJDIR}/*
If you can tolerate errors in the output, the following is
faster because the chflags has lots less work to do:
realclean :
@rm -Rf ${.OBJDIR}/*
@chflags -R 0 ${.OBJDIR}/*
@rm -Rf ${.OBJDIR}/*
The more foolproof/reliable we can make it for everybody, the
more I like it. I'll see your chflags, and add one redirection
of stderr so the user won't see errors that we don't really
care about:
realclean :
@rm -Rf ${.OBJDIR}/* 2/dev/null
@chflags -R 0 ${.OBJDIR}/*
@rm -Rf ${.OBJDIR}/*
Any errors that showed up on the first 'rm' should also show up
on the second 'rm', so we shouldn't really lose any useful info.
I might also try wrapping the second two commands in an 'if', so
they will be executed only if there's still something left over
after the first 'rm'.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding 'realclean' target to /usr/src/Makefile
At 10:19 AM -0700 2/15/04, M. Warner Losh wrote:
If you can tolerate errors in the output, the following is
faster because the chflags has lots less work to do:
realclean :
@rm -Rf ${.OBJDIR}/*
@chflags -R 0 ${.OBJDIR}/*
@rm -Rf ${.OBJDIR}/*
After some testing, I am planning to go with:
Index: Makefile
===
RCS file: /home/ncvs/src/Makefile,v
retrieving revision 1.292
diff -u -r1.292 Makefile
--- Makefile9 Dec 2003 02:08:19 - 1.292
+++ Makefile16 Feb 2004 00:29:54 -
@@ -104,6 +104,21 @@
.endif
#
+# This 'realclean' target is not included in TGTS, because it is not
+# a recursive target. All of the work for it is done right here.
+# The first 'rm' will usually remove all files and directories. If
+# it does not, then there are probably some files with chflags set.
+# Unset all special chflags, and try the 'rm' a second time.
+realclean :
+ -rm -Rf ${.OBJDIR}/* 2/dev/null
+ @-if [ `echo ${.OBJDIR}/*` != ${.OBJDIR}/* ] ; then \
+ echo chflags -R 0 ${.OBJDIR}/* ; \
+ chflags -R 0 ${.OBJDIR}/* ; \
+ echo rm -Rf ${.OBJDIR}/* ; \
+ rm -Rf ${.OBJDIR}/* ; \
+ fi
+
+#
# Handle the user-driven targets, using the source relative mk files.
#
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
If the first 'rm' works, the other two commands will not be
executed, and the user will only see the first 'rm'. If the
other two commands are executed, then the user will also see
echoed-versions of those commands before they are executed.
So, if there is some chflag'ed file in /usr/obj/..., what the
user sees is:
(330) keep-talking/root # make realclean
rm -Rf /usr/obj/usr/src/* 2/dev/null
*** Error code 1 (ignored)
chflags -R 0 /usr/obj/usr/src/*
rm -Rf /usr/obj/usr/src/*
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Adding 'realclean' target to /usr/src/Makefile
In the instructions I am writing up for a sparc64 change, I wrote
that people should:
rm -Rf /usr/obj/usr/src/*
to make sure they got rid of everything in the previous buildworld.
Some developers reminded me that this isn't always the right thing
to do (depending on symlinks or on various settings the user may
have set). Some suggested 'rm /usr/obj/*', but I do not like that
because I have other things in /usr/obj that I don't want to blow
away. And besides, even that can be wrong if the user has set
something like MAKEOBJDIRPREFIX.
It occurs to me that the simple, reliable solution to this is to
add a 'realclean' target to /usr/src/Makefile, such as:
realclean :
rm -Rf ${.OBJDIR}/*
Another option is to put that into /usr/src/Makefile as the
'cleandir' target. Right now that 'cleandir' target goes to the
extra work of looping through all subdirectories, and having
*those* Makefiles do whatever they want for a 'cleandir' target.
This includes printing out all kinds of status messages, and
frankly seems like a waste of time to me. I'd rather type in the
'rm' command by hand then wait for that target, but I expect that
behavior serves a purpose, so I'm suggesting the new target.
Seeing that this is in /usr/src/Makefile, and that it's a simple
two-line change, I'm sure there's at least a hundred developers
who will have strong opinions about it. So, should I do it, or
will I be beaten around the head and shoulders for suggesting it?
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
At 10:00 AM + 1/11/04, Doug Rabson wrote: On Sun, 2004-01-11 at 00:05, Peter Jeremy wrote: I disagree. Andrew raised two issues (type of license and port vs base location). The type of license is an input to the decision as to which SCM to choose - BSD preferable ... Subversion has a friendly BSD-ish license but it depends heavily on Sleepycat DB which doesn't. I imagine that if we do end up using it one day, it would be best managed as a port rather than part of the base system. I just don't see many people agreeing on importing subversion+db-4.2+apache2 into src/contrib... Another way of approaching that is to say subversion is not-likely to be imported *unless* we can find an acceptable BSD-licensed database mgr to go along with it. (I do not know how much of Apache is needed. Would svn *clients* need to have apache installed, or is that only needed for machines that hold a public repository?) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
At 7:27 PM -0800 1/9/04, Pedro F. Giffuni wrote: Hi; There is a comparison here: http://better-scm.berlios.de/comparison/comparison.html I think there are compelling reasons to try subversion, but we have to wait for a 1.0 Release, and this would be something that should be done gradually.. for example moving the ports tree first. That's a pretty major test! Could we perhaps pick off something smaller? The projects repository, for instance? (or is that still tied to the base-system?) (I am very interested in subversion, but it is still something I need to learn more about...) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
At 9:05 AM -0800 1/10/04, Pedro F. Giffuni wrote: --- Garance A Drosihn [EMAIL PROTECTED] wrote: That's a pretty major test! Could we perhaps pick off something smaller? The projects repository, for instance? (or is that still tied to the base-system?) SVN is meant to be a replacement to CVS. The projects repository is using perforce which happens to be a good tool, ... Ah. I did not realize it was already using Perforce. Yeah, I would not suggest making that change. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCM options (was Re: Where is FreeBSD going?)
At 9:35 PM + 1/10/04, Andrew Boothman wrote: Peter Schuller wrote: Most of the noteworthy features of subversion are listed on the project front page: http://subversion.tigris.org/ A significant one of which is the fact that it's available under a BSD-style license. Meaning that the project wouldn't have to rely on more GPLed code. I wonder if our SCM would be brought into the base system or whether it would just be left in ports? We haven't even started to *test* subversion yet, so I think it's a bit early to worry about this question! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
At 12:42 PM +0100 1/7/04, Dag-Erling Smørgrav wrote: Paul Robinson [EMAIL PROTECTED] writes: If 5.3, when it arrives, is genuinely production ready, trust me, the drinks are on me - I will do my absolute best to get to the next BSDcon and get everybody drunk on an expense account. If it isn't, well, I'll just have to whisper I told you so quietly somewhere. I am currently working for an ISP whose infrastructure is based 75% on FreeBSD 5.1. ... I am about to start in a new job... I asked them what it was like to develop on -CURRENT compared to -STABLE. Their answer: a relief. I would add that I've been running almost exclusively on 5.x for over a year now (except for one machine which I have not rebooted in over a year...). There have been some *very* painful transitions at various times, but once I get past the transitions the system has been quite stable. (fwiw, in my case, I am only running on desktop systems). So, once we stop making major API/ABI changes and the branch is truly stable (with a 6.x branch for new cutting-edge developments), I personally am quite confident that 5.x will be a stable, production-quality system. And there are a number of features in 5.x that I think are tremendous advantages -- especially for boxes in a production setting. My guess is you're going to have a large bar tab at the next BSDcon... Certainly I hope so! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
At 9:57 AM -0500 1/7/04, Leo Bicknell wrote: Speaking with a user hat on, I'll comment on what I believe is the crux of the 5.x issue. The take away I see is that this was too big of a chunk. The next bite planned needs to be smaller. I agree with this observation, but then it's easy to see that in hindsight. We started on some ambitious targets when 5.x started, and at the time we believed we were going to have a lot more full- time development resources than we ended up with. That whole big problem with the dot.com bubble bursting. I do think we need to tackle a somewhat smaller chunk of projects for 6.0, so it won't take so long to get it done. I also expect we have a much more realistic idea of what our resources are than we had in late 1999. You can't delay one year or two years in a production environment. Actually, in a production environment you're more than happy to delay a year or two. You don't want constant churn. You don't want new API's and ABI's every year. The problem for freebsd is that 4.0 was released in March of 2000, and that was advertised as a stable release. 5.0 was released in January of 2003 -- and was explicitly *not* a stable release. We could stand to have a major stable release every two years, or maybe even every three years, but this is going to be more like four years. That is too long. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FBSD 5-CURRENT: Kernel Makefile.inc1 Error
At 12:41 PM -0500 12/8/03, Damian Gerow wrote: Thus spake Garance A Drosihn ([EMAIL PROTECTED]) [06/12/03 03:31]: From the above description, it sounds like you are running on a 5.1 system, and you are trying to compile a 5.2 kernel. Is this true? If the system you are on is 5.1, then you are going to have to do a 'make buildworld' of the 5.2-source before you can do a 'make buildkernel' of a 5.2 kernel. It's not clear from what you're saying, but will this cause problems with the statfs stuff? I've been under the impression that a 5.1-5.2 upgrade requires me to build and boot a new kernel before I can install a new world -- it's not clear if you're saying I need to build /and install/ a new world before building a kernel, or if I just need to build world... My comments were not trying to cover the installation steps. All I said was that you have to do a BUILDworld before you do a BUILDkernel, because it sounded to me like you might have been building a 5.2 kernel without doing any matching buildworld. You can get through the statfs changes by following the standard recommended buildinstall order. The standard recommended order is: make buildworld make buildkernel make installkernel reboot into single user mode mergemaster -p make installworld mergemaster reboot into nicely-upgraded system Many developers have gotten away with shortening this list, or with an alternate order. For the statfs change, it is particularly important that the proper order be followed. For this change, you really need to do that installkernel and *reboot* before doing the installworld. depressing aside Oh, and due to a small-but-significant bug in one of the makefiles, you would be well advised to make sure that you do not set the 'DISTDIR' variable. You might have that set in /etc/make.conf, expecting it to be used by the *ports* collection. Right now there is a problem where it is also checked during installworld, and the makefile will not do the right thing if that is set. We hope to have that sorted out very soon... /depressing -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Reward for fixing keyboard support in FreeBSD, apply within
At 6:13 PM +0100 12/7/03, Blaz Zupan wrote: In the last couple of days I've been fighting with a evaluation IBM BladeCenter. [...] My company would really like to deploy the Bladecenter as it is otherwise a very solid solution for our problem. But 99.9% of our servers are FreeBSD and the above problems are a real showstopper. That's why I'm offering a reward to anybody who produces working patches that are polished enough to be included both in -stable and -current. I will do my best to provide all the neccesary information as well as an account on the box. This is not a project I could take on, but it is nice to see someone offer a real reward to have this fixed. Hopefully some developer can take you up on that! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FBSD 5-CURRENT: Kernel Makefile.inc1 Error
At 1:45 AM -0600 12/6/03, William M. Grim wrote: Hey there! I'm having a slight problem performing a build on my FreeBSD 5.1 machine. I downloaded the 5-CURRENT source code and only added the line, device pcm to the GENERIC kernel, renaming it to ZEUS. Then, I went into /usr/src and typed make buildkernel KERNCONF=ZEUS, and it immediately came up with the errors [...] From the above description, it sounds like you are running on a 5.1 system, and you are trying to compile a 5.2 kernel. Is this true? If the system you are on is 5.1, then you are going to have to do a 'make buildworld' of the 5.2-source before you can do a 'make buildkernel' of a 5.2 kernel. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Experimental FreeBSD and Linux kernel source cross reference web site
At 11:18 PM -0500 10/29/03, Robert Watson wrote: In the past when browsing the Linux source code, I've made extensive use of the Linux Cross-Reference (LXR) hosted at lxr.linux.no. For FreeBSD, we provide a cvsweb interface that is extremely useful for tracking changes, but a little less useful for raw browsing when you're looking for use of an identifier. In the past, CMU's PDL (and possibly others) have provided FreeBSD cross-reference web pages, but I was unable to find one once that site went down. How about http://snapshots.jp.FreeBSD.org/tour/ ? That's what I have used from time-to-time, when on a random goose chase for various variables... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sshd source code
At 7:08 PM -0400 10/16/03, Adil Katchi wrote: I'm looking for the sshd source code for freebsd 4.7. Any idea where I can find it in the CVS tree? if you have the source tree on your machine (and if it has been there for a week or so), then use the 'locate' command: locate openssh You'll get a list of files... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
At 10:23 AM -1000 9/16/03, Clifton Royston wrote: In the meantime I'm trying to figure out if there's some simple hack to disregard these wildcard A records, short of requesting zone transfers of the root nameservers (e.g. via peering with f.root-servers.net) and purging those records out of the zone before loading it. Any ideas, either under djbdns or Bind 9? The story at http://daily.daemonnews.org/view_story.php3?story_id=4068 notes that there is a patch for dnscache at: http://tinydns.org/djbdns-1.05-ignoreip.patch someone also posted a likely update for bind 9 to slashdot: http://slashdot.org/comments.pl?sid=78637cid=6973033 (also available in a uuencoded version at: http://slashdot.org/comments.pl?sid=78637cid=6972991 ) I have no idea of how well either of these work. Use your own discretion at applying them. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A new sort utility
At 8:53 PM +1000 9/15/03, Tim Robbins wrote: Comments/patches are welcome. As the History suggestion of the manual page suggests, my plan is to get this in to FreeBSD 6, along with replacements for some other GNU tools. Might we put this in freebsd-current (5.x), but under some other name? sortbsd, or something? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A new sort utility
At 9:47 PM -0400 9/15/03, Richard Coleman wrote: Garance A Drosihn wrote: At 8:53 PM +1000 9/15/03, Tim Robbins wrote: Comments/patches are welcome. As the History suggestion of the manual page suggests, my plan is to get this in to FreeBSD 6, along with replacements for some other GNU tools. Might we put this in freebsd-current (5.x), but under some other name? sortbsd, or something? Why would you want to do that? Just so we could have it in 5.x, instead of the stated plan of waiting until 6.x. I do not feel strongly about it, other than to say that it'd be nice if this was part of 5.x, and I don't know if we want to switch to rewrite of 'sort' at this point in 5.x. *Someday* we've got to stop dropping in major changes to 5.x, and get serious about releasing it as -stable so we can start on 6.x-current. Just my 2 cents. I don't feel strongly about it. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getfsent(3) and spaces in fstab
At 10:16 PM -0400 7/31/03, Chris BeHanna wrote: Sorry, I should have written that I have performed tests: Here is what I did: test\ 1 /mnt/test\ 1ufs ro 0 0 'test 2''/mnt/test 2' ufs ro 0 0 test 3/mnt/test 3 ufs ro 0 0 [...etc...] What about test%201/mnt/test%201 ufs ro 0 0 ? Ugly, yes, but that's how a lot of tools escape spaces. There may be people who already mount directories with %'s in them. If you wanted to be fancy, there could be some kind of trigger that says after this point, recognize URL-style escaping rules. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: generalized mergemaster(8)
At 10:15 AM -0800 3/21/03, Tim Kientzle wrote: On Thu Mar 20, 2003, Brandon D. Valentine wrote: I need to recursively merge two directories of source files in which I wish to preserve some original files, install some replacement files outright, and only actually go to the trouble of sdiff(1)ing those files that from the preview udiff look like they are need of a merge. One feature I've long wanted to see in mergemaster is the ability to install an entire directory at a pop, without having to manually inspect every single entry in that directory. A good example is /etc/rc.d/ . I would really like to be told /var/tmp/temproot/etc/rc.d/ and /etc/rc.d/ have 17 differing files. (I)nstall, (D)elete, or (R)ecursively examine? [R] Then I could hit 'I' and update all of /etc/rc.d at once. At times I've asked Doug about some kind of pattern-support in ~/.mergemasterrc, where the user could specify filename-patterns of files where they want the default action to be install instead of leave for later. There are pros and cons with that idea, but that's what I was thinking of for the directories you describe. Doug has suggested that people could maybe do things with the MM_PRE_COMPARE_SCRIPT, for special processing like this. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: lpc problem with LinkSys print servers
At 11:31 AM -0600 3/3/03, Peter Elsner wrote: This particular printer is a high load printer, printing about 50 to 70 pages at a time. Occasionally, the printer just stops while printing. We have to force a 'lpc restart lsjd1p2' command several times to get the printer to restart again. You will sometimes have better luck if you 'lpc abort' the queue, wait a few seconds, and then 'lpc start' it. Of course, that doesn't solve the actual problem... I believe that lpr/lpd is not resetting after receiving a Busy/Ready (or Nack/Ack) signal. Has anyone else seen this problem before? I have not heard of it. I'd like to see some actual proof of what is happening (like a tcpdump) before assuming that it's lpd's fault. Mind you, I'm quite willing to believe it's lpd's fault, but I can't very well look into the problem unless I know what sequence of packets is causing it. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: scan_ffs for UFS2
At 3:40 PM +0100 2/23/03, Michael Ranner wrote: Am Freitag, 21. Februar 2003 Garance wrote: I don't know how find-sb compares to the program you're talking about, but they sound kind of similar. Scan_ffs can print the lost disklabel for use with disklabel(8). Find-sb, that version from cvs, seems only to print info about the superblocks of each file system and you have to rebuild the lost disklabel for your self. [...] I don't know what find-sb could do with your patches applied. If it's superior to scan_ffs, we can forget scan_ffs. It sounds like you should go with scan_ffs, and when I have the time to sort out my updates I'll see how they apply to that. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: scan_ffs for UFS2
At 10:20 PM +0100 2/19/03, Michael Ranner wrote: Hello! I am trying to learn scan_ffs (original from OpenBSD, ported to FreeBSD by Robert Watson) about UFS2 on 5-CURRENT, but it will not find the Superblock and I dont understand exactly both for loops, especially that 512 byte increment. Scan_ffs is a system tool from OpenBSD to recover erased disklabels from your hard drive. Thanks for your input. For what it's worth, we (FreeBSD) have a simple SuperBlock recovery program in /usr/src/tools/tools/find-sb. I picked up some updates from Dave Cross for that, and have a few more of my own. I just have to sit down and get them all together into a single version. I don't know how find-sb compares to the program you're talking about, but they sound kind of similar. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: where's my pr gone? - supplemental
At 12:05 AM +0100 2/16/03, Friedemann Becker wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/47512 this happens only with the above link, i.e. from the pr summary. searching for the bugid 47512 works (= not empty) someone want to look at this? The above link worked fine for me. I did not get a blank page. Also, doing an 'ls' in bash, after starting 'gdb bash', did not cause any kernel panic. But then it occurred to me that my login shell was bash (ie, I was already in bash when I typed the 'gdb bash' command). So, I logged into 'toor', which has /bin/sh as the login shell. If I logged in at the console, and did a 'gdb bash', then when I tried to do a 'run' I was told: Starting program: /usr/local/bin/bash Cannot exec : No such file or directory So, then I ssh'ed into 'toor', to make it easier to copypaste that error message into this email. Behold, it worked fine. Well, there was a complaint of: Starting program: /usr/local/bin/bash warning: shared library handler failed to enable breakpoint but other than that warning it worked fine (as did the 'ls'). Sooo, then I checked to see what the difference was between the two sessions. It turned out that when logging into the console, the SHELL environment variable was set to the null string. When I ssh'ed in, it was set to /bin/sh. If I set SHELL on the console session, then gdb could run bash OK. I'm not quite sure what all of that means... All of this was done an a FreeBSD 5.0-CURRENT system, built on Sat Feb 15 01:34:07 EST 2003 -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Trailing whitespace in FreeBSD
On Monday, February 10, 2003, at 03:00 PM, Simon L. Nielsen wrote: I have noticed that that several FreeBSD files (.c, .h and so on) have trailing whitespace (spaces/tabs after last charecter on a line). Should I send patches for this, or is it not important to fix? It might be nice to fix, in some abstract sense, but it drives developers nuts if you modify a file that they've checked out a local copy of. They go to commit their change back in (a change which is usually something more significant than a damn trailing blank or tab character), and the commit runs into a conflict because someone else has cleaned up the source code. So, this is something that a developer might want to do if they are going to be working on some source file anyway. However, it can really irritate a lot of developers if it is done across the entire src tree just because it is easy to do. Further, IMO it doesn't really help the FreeBSD project at all. Imagine a new release which said And now with less blanks in the source code! for the release notes. Our end-users would think we are nuts. It is better to tackle a harder project -- one which has an actual payback to the end users -- instead of looking for something this easy to do. Just my 2 cents. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
At 3:21 AM -0800 2/5/03, Doug Barton wrote: On Mon, 3 Feb 2003, Amit Rao wrote: Allow users to pass regexps to ignore as an option? similar to: diff --ignore-matching-lines=\$FreeBSD: ? I decided to be more general, and added the DIFF_OPTIONS variable to the script, and an example of -I$FreeBSD:.*$ to the man page. Well, this gets into an interesting exercise in quoting... I think I really want: DIFF_OPTIONS='-I $FreeBSD:.*[$]' to get the behavior I wanted, because the pattern should match a literal $, and not have the $ be treated as to end-of-line. I think my reasoning is correct there. It also seems to work right with or without the blank after the -I. Also note that the example in the man page expanded to: #DIFF_OPTIONS='-I$FreeBSD: src/usr.sbin/mergemaster/mergemaster.8,v 1.25 2003/02/05 11:03:05 dougb Exp $' # Ignores CVS Id tags which would probably baffle anyone who reads it! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [eugene@securityarchitects.com: Re: Preventing exploitationwith rebasing]
At 2:10 PM -0600 2/4/03, Brandon D. Valentine wrote: On Tue, Feb 04, 2003 at 11:51:14AM -0800, Justin Lundy wrote: Has similar work been done in FreeBSD been done? This would be a nice feature in 5.0-CURRENT. We had SecureBSD, and the IBM port of propolice, but both projects appear to be defunct at present. It would be much smarter to follow what OpenBSD is doing with propolice, and revive a freebsd project of *that*. - Forwarded message from Eugene Tsyrklevich [EMAIL PROTECTED] - Add a possibility to add a random offset to the stack on exec. This makes it slightly harder to write generic buffer overflows. This doesn't really give any real security, but it raises the bar for script-kiddies and it's really cheap. AFAIK, no. No similiar work has been done in FreeBSD. Personally I think if one is going to expend effort in making the stack more secure the proper way to do this is to follow NetBSD's example and switch to a signal trampoline provided by libc so that stack pages can be marked non-executable in the first place. Adding random offsets to the stack is never going to be more than a hack. I agree that random offsets will not buy much in the way of security, but it might make some kinds of initialization errors more obvious. I'm thinking of the kind of errors where a routine forgets to initialize a key variable, but everything seems to work because the routine happens to always pick up the same value off the stack. By adding random offsets, the routine *might* at least behave differently each time it's run. Okay, I'll admit that even that is a bit of a long-shot... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
At 11:43 PM -0800 2/4/03, Doug Barton wrote: On Tue, 4 Feb 2003, Garance A Drosihn wrote: At 10:36 PM -0800 2/3/03, Doug Barton wrote: There's a section of mergemaster that starts out with the comment Do an absolute diff first to see if the files are actually different. That's an option that users can enable, it's not the default behavior. What I was saying is we should add the same -I argument to that diff command, That's not going to happen... the whole point of strict comparison mode is that ALL differences are displayed, no matter what. Since users choose this option, it's reasonable not to change its behavior. Oh, I didn't realize that was an optional behavior, I thought that was the default code path. That request is my mistake then, for skimming through the script a little too quickly. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
At 9:12 AM -0800 2/3/03, Doug Barton wrote:
On Mon, 3 Feb 2003, Dag-Erling Smorgrav wrote:
Doug Barton [EMAIL PROTECTED] writes:
On Tue, 28 Jan 2003, Garance A Drosihn wrote:
Well for one thing, if a given file has a lot of changes, then I
would like mergemaster to skip over the initial one-line change
that only tells me how some comment now has a new version-number
in it.
This is an oft-requested feature, but I'm not sure how best to
implement it.
Look up the -I option in the diff(1) man page.
I didn't say I don't know HOW to implement it, I said I didn't know
how BEST to implement it. You snipped the part of my e-mail where I
explained the issues.
I happen to be updating my system tonight, so when it came to the
mergemaster step I first modified the script. I added:
-I '$FreeBSD:.*$'
to the 'diff ${DIFF_FLAG}' command in diff_loop, and it seems to have
worked the way I wanted it to work. From my skimming of the script,
I do not see how this change would cause problems for any other
processing. However, it's possible I'm missing something. If so, my
gut reaction is that if a lot of FreeBSD users are requesting this,
then we should figure out how to make it happen -- one way or another.
I suppose we should also change the 'absolute diff first' part to
include that, or people will be asked about merging a file, only
to be shown a file which apparently has zero changes.
I'd also note that the separator line (=) is usually scrolled
off the window for me. Not much point to a good eye-catching line
if the line is usually not on the screen. Shouldn't that be moved
inside the
( ... ) | ${PAGER}
lines? And (IMO) delete one of the blank lines that are printed
out between the separator and the Displaying differences line.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
At 10:36 PM -0800 2/3/03, Doug Barton wrote:
On Mon, 3 Feb 2003, Garance A Drosihn wrote:
I added:
-I '$FreeBSD:.*$'
to the 'diff ${DIFF_FLAG}' command in diff_loop, and it seems to
have worked the way I wanted it to work.
How did you want it to work? (This isn't a rhetorical question.)
I do not care to see what the version-string is, and I certainly
don't need to see the two un-changing lines before and after the
version-string. When you also count the diff-output line which
gives the line numbers of the change, that's a total of six lines
which appear on the screen and which give me (IMO) very little
useful information.
Try -I and watch how it behaves. It isn't exactly what I was asking
for, but it is close enough that I think it would be a helpful step
forward from the present behavior.
From my skimming of the script, I do not see how this change would
cause problems for any other processing.
What do you think mm should do if the only diff between two files
is the cvs ID?
see below.
I suppose we should also change the 'absolute diff first' part
to include that, or people will be asked about merging a file,
only to be shown a file which apparently has zero changes.
I'm sorry, I don't understand exactly what you're getting at here.
There's a section of mergemaster that starts out with the comment
Do an absolute diff first to see if the files are actually different.
What I was saying is we should add the same -I argument to that
diff command, so that if a file only differs by the version string,
then the absolute diff will not consider it a change.
In thinking about it now, I realize that I (personally) would
prefer that mergemaster would just install the file in that case,
but the result of adding the -I to that diff command is that the
file would be quietly skipped over. I could live with that too,
but I'd feel better to have it automatically installed. JMO.
If so, my gut reaction is that if a lot of FreeBSD users are
requesting this, then we should figure out how to make it
happen -- one way or another.
What I was getting at is that mergemaster is going to be run fairly
often by a significant number of freebsd users. If we need make some
changes to make that process more pleasant, then I think we should
feel free to do that. If people aren't happy with how -I works, then
we should consider adding some different option to diff which will
do the job.
I would rather see a few lines added to diff, then having the
script do a bunch of back-flips and multiple runs of diff to get
the desired behavior. I'd also prefer those lines added to diff
than to say it's too hard to get the desired behavior, so let's
not bother.
The request I actually get is that if the only diff is the cvs ID,
that mm should do X various things with it. Most commonly, just
install the file (which I'm opposed to on principle, and by
fundamental mm design).
Mergemaster has the -'i' option to automatically install new files.
Perhaps the same option could control whether it automatically
installs files where the only change is to the version string
which is in a comment line.
Trying to deal rationally with this scenario is why I'd have to
add at least one more diff to the process.
1. Are the cvs id's different?
2. If so, is that the only difference? --- new
3. If cvs ID is not the only diff, display that to the user.
What I would ideally like is some option to diff where diff itself
understands what a version-string is, and it prints out a header
line that includes the version-string change. But the way -I
works is fairly close to what I want, and is probably less
objectionable than adding some rather specialized option to diff.
I'd also note that the separator line (=) is usually scrolled
off the window for me. Not much point to a good eye-catching line
if the line is usually not on the screen.
That's actually a good thing. [...] Passing it to PAGER when the
diff already fills a page is a waste of screen space.
That line is more useful to me than the six lines of space used up
by telling me that the file is now 1.7.12 instead of 1.7.10. This
is my opinion. Other people have theirs, this one is mine.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Lower power SMP boxes?
At 3:12 PM -0800 1/31/03, Matthew Dillon wrote: But MP is another story. At some point I would like to put together some SMP test boxes that don't cost the equivalent of rent on a small apartment in electricity use. They don't have to be super-fast, they just need to be SMP. I'm not talking about blade servers here, I'm talking about SMP boxes for testing purposes. Anyone have any ideas? The arrival of FreeBSD/PPC might give you some cheaper options. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pw(8): $ (dollar sign) in username
At 12:45 PM -0500 12/27/02, Craig Rodrigues wrote: On Fri, Dec 27, 2002 at 11:35:45AM -0600, Ryan Thompson wrote: Problem is, smb requires a '$' at the end of the username, which our pw(8) doesn't allow. The same patch which you proposed was suggested on the freebsd-current list. See the thread pw_user.c change for samba: http://docs.freebsd.org/mail/archive/2002/freebsd-current/20021201.freebsd-current.html http://docs.freebsd.org/mail/archive/2002/freebsd-current/20021208.freebsd-current.html I'm not sure what the outcome of the discussion was. The short-term outcome was that we were surprised to find out that the adduser script in 5-current was still using perl, and that there were some other perl scripts still in the base system. This was much more urgent to address than the $ in user-names. My intention was to write an update to allow $ as the last character in a userid and groupid, once we settled on a new version of adduser. I still have that around somewhere. I should look into that again. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Bootable FreeBSD CD
At 7:12 PM -0800 12/20/02, Sean Hamilton wrote: Greetings, How does the kernel on the FreeBSD install CD know which device to mount as root? I'm assuming it hasn't got a ROOTDEVNAME config option, since that would make it fairly specific to certain hardware. Mine always tries to mount fd0. You might want to check out http://www.sourceforge.net/projects/freebsdtogo/ It might be helpful for whatever you're trying to do... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: utmp/utmpx improvement
At 10:48 PM +0100 12/19/02, Michael Ranner wrote: Hello! I have done some research for utmp improvement for FreeBSD and found the following URL which sounds very intersting: http://lists.debian.org/debian-bsd/2002/debian-bsd-200202/msg00142.html The author has posted an article in freebsd-hackers earlier this year. What is the current status? Any interest to integrate this in FreeBSD. There definitely is interest. The Nathan Hawkins also sent a message to freebsd-standards back in April, although at that time he said the reentrant versions weren't quite finished yet. I think this is one of those things which we just lost track of due to so much else going on in freebsd-current at the time. I saved the messages back in april, and some other message on utmpx, and then completely forgot about it... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fw: lpd and lprm broken?
On 11/25/02, Peter Elsner [EMAIL PROTECTED] wanted to know: Hello All... Something appears to be broken with lpq and lprm. I'm writing a Perl script to easily allow users to manage printers/jobs from a easy to use interface. 1st problem (lpq): man lpq displays the use as follows: NAME lpq - spool queue examination program SYNOPSIS lpq [-a] [-l] [-Pprinter] [job # ...] [user ...] lpq -a (works fine) lpq -l (doesn't return anything) lpq -Pprinter (works fine) lpq job# and lpq user (don't work). 'lpq -a' will check all local printer queues for any queues which have jobs waiting for them. It is the only option which checks all queues. If you do not specify '-a', then lpq will check only one queue for print jobs. By default, that single queue will be the one named 'lp', unless you have defined and exported the environment variable PRINTER. In that case, it will check whatever single queue is specified by PRINTER. The same is true for 'lprm'. It will only look at one single queue for the job or jobs that you are trying to remove. Now, it does work if (and only if) I enter the following: lprm -Plsjd1p2 13 spxdev:root# lprm -Plsjd1p2 13 dfA013spxdev.servplex.com dequeued cfA013spxdev.servplex.com dequeued (LPD Server): Cancel Function Not Supported spxdev:root# It does actually remove the print job but still gives the Cancel Function Not Supported message... The Cancel Function Not Supported message does not come from lprm or lpd. The queue named lsjd1p2 is probably pointing at some remote machine (either the printer itself, or maybe a print server that is between you and the printer). Given the look of that error message, I would guess that you're talking to the printer itself, or an LPD server which is running on some flavor of Windows. When removing jobs, lpd first removes any jobs on the local machine which match the criteria you gave. It then sends the exact same criteria on to the remote host, so it can delete any jobs which match your request. In this case, the local host was able to delete the one job, and when it asked the remote machine to delete the same job, the remote machine said that it does not support the cancelling of any jobs. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [ GEOM tests ] vinum drives lost
At 9:02 PM +0200 10/4/02, Poul-Henning Kamp wrote: There are numerous architectural issues which have never been fixed in vinum, and one or more of these bits now. Whoever loves vinum will have to chase it/them down and fix it. If I receive patches or requests for changes to GEOM as result of this, they will be evaluated in good faith. Worst case you will have the option to use: options NOGEOM options vinum I know nothing about vinum and only a little about GEOM, so I have no opinion on which should be fixed to work with the other, and I'm reluctant to get drawn into that battle anyway. However, I do think that if it isn't easy to get the two of them to work together nicely, then we should enforce the above options in the source code. Ie, if someone tries to compile a kernel with both GEOM and vinum turned on, then the compile should fail with some suitable error message. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
At 10:11 AM +0200 10/3/02, Mark Santcroos wrote: On Thu, Oct 03, 2002 at 09:04:04AM +0100, Ian Dowse wrote: See the patch I posted in: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+6285+/usr/local/www/db/text/2002/freebsd-emulation/20020908.freebsd-emulation There may still be further issues, but it allowed me to use vmware2 on a current from a week or two ago. That's only for virtual disks, and that is not where the problem is (was). For most people this is not a solution. I have an almost-ready patch that implements linux_read() syscall. This will check if we are reading from a raw disk and in that case it will enlarge the read() to the next sector boundary. I have it working in the kernel but I have problems returning the right read buffer to userland. Hmm. I might not be any good for the raw-disk testing. All I use are virtual disks. (I have a 32-gig disk with a bunch of 2-gig virtual-disks on it. With that many systems, it's much easier for me to deal with files than a whole bunch of small partitions on the raw disk). The patch from Ian sounds like it would be interesting for me. I'll have to try that. It would be great if I could get back to regularly running an up-to-date current. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Request for submissions: FreeBSD Bi-Monthly DevelopmentStatus Report (fwd)
At 8:45 PM -0400 7/18/02, Robert Watson wrote: I've seen many base system developers commit man pages, but few commit to the docbook/sgml side of things in the doc project. [...] The FreeBSD src developer community is, after all, a community of people who write software that frequently ships with man pages. Sure, the nroff markup may not be the best, but it's still workable. In my case, I don't actually know nroff. I just look at other man pages and copy what they seem to be doing... On the other hand, I know even less about sgml. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Adding readdir entries to the name cache ...
At 6:29 AM +0930 7/6/02, Richard Sharpe wrote: Hmmm, I think that the major part of the problem there was that, for what ever reason, Barry Feigenbaum of IBM, declined to add a Change Working Directory or Set Working Diretory command to the SMB protocol. Thus, at least for the SMB protocol, and maybe generally, Windows clients must always send the full pathname for every file they want, unless it happens to be at the root of the share. Could the unix process for samba fake that? Keep track of the most recently used directory, and when a new request comes in split it into directory plus filename, and if the directory is the same as the previous one, then just access the filename. If the directory is different, try to do a chdir() to the new directory, and if that succeeds then save that as the previous directory. Or is that more trouble than it's worth? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: AMI MegaRAID + Reboot issues
At 4:49 PM +0100 7/2/02, Byron Schlemmer wrote: Hi, I've posted on this before, and I've received no reply. I'm cross-posting just in case it was missed before (I am desperate for help) and to ask for further advice. Basically we have a number of FreeBSD servers, running 4.5-RELEASE and 4.6-RELEASE, that use AMI MegaRaid 500 controllers. These boxes refuse to reboot when sent a reboot or shutdown -r. They simply close all processes and show : amr0: flushing cache...done Rebooting... At this point the numlock key is locked, and Ctrl + Alt + Deleting does nothing. This will not help much, but I can at least say that I have noticed your messages go by. Unfortunately I have no experience with any raid controllers under freebsd. If you made it successfully to the Rebooting... line, then I think it's at the point that freebsd has done everything it expected to do, and freebsd has told the hardware to reboot. I do not know why the hardware wouldn't reboot at that point. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEYsupport considered harmful?)
At 2:37 PM -0400 4/23/02, Robert Watson wrote: Here I'll disagree with you: we make a concerted effort to produce a system that is safe to use. This involves a number of things, and it doesn't just mean security fixes. I would argue that we have a moral obligation to do so. I agree that there is this obligation. I also observe that the internet is unquestionably getting to be a more hostile place, and we have to adapt the system to stand up to that hostility. Let me claim that it is fact that we will have to make changes to the default system configuration, and that we will also have to make changes to the preferred system configurations when someone is just upgrading. I recognize that some people disagree with that (particularly the second half), but let me claim that for the moment. I think an important component of any such change is making sure the right people find out what changed, and that they get this information when they *need* it, and not as part of some 20,000 line README file which we know no one will read because it's too damn big. In the case of the sshd change, the change was simply wrong and should be fixed. Just MO... :-) In the case of the 'startx -listen_tcp' option, is there some thing we could set up so a person who *wanted* the former behavior is given quick notification of exactly why things suddenly stopped working. Note that the person who runs into the problem is not necessarily the same person who did the system upgrade. I think it's doable, if we just took the attitude that it needed to be done. Some of these changes catch me offguard too, and most of the time it is not the change itself which bothers me, it's the six hours I spent trying to find out why something stopped working. (a six-hour period which may not start until a week or two after the system upgrade...) I think that's the part we need to improve on. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEYsupport considered harmful?)
At 8:44 AM +0930 4/24/02, Greg 'groggy' Lehey wrote: On Tuesday, 23 April 2002 at 12:06:01 +0200, Jochem Kossen wrote: *shrug* I was the one who sent in the patch. It was added some time around 2001/10/26 to the XFree86-4 megaport. When the metaport was created, the patch was incorporated too. A simple 'man startx' should have cleared your mind: Well, yes. But I've been using X for 11 years. Why should I have to read the man page to find changes? I think the first thing we need to do, before we get too worked up, is stop taking to Jochem about it. All he did was send in a PR with a suggestion. He's not responsible for the change being committed into the system. How do I know which man page to read? You start X with startx, seems obvious to me. The disabling of tcp connections only applies to startx I don't stay with startx. Next I go to xinit, then to Xwrapper, then to X. All of these work fine. When I try to start an xterm, nothing happens. This is where we (the freebsd project) need to take a bit more time at when we are making a change like this. I think it makes little difference whether we document the change in UPGRADING, or man pages, or heads up on the mailing lists, or errata.html pages on the web site. There will always be some people who are not going to see documentation like that, because it's too far out of the way of what they are doing. What we need, in this case, is something which gives the user the information when they do that *xterm* -- ie, at the time of failure, to the person who is seeing the failure. For the case of 'startx -listen_tcp', this might suggest that if a person uses startx without -listen_tcp, then startx should (one way or another) start some process which *does* listen for an incoming connection, and does nothing but tell the user (one way or another...) when that connection comes in. Yes, that's a bit of work. However, it is also a bit of work when someone (like Greg) wastes six hours of a day trying to understand why something broke. That's a very frustrating six hours of work, and it's also very useless. His six hours of work won't help anyone else when they have to track down the same issue. A simpler solution might be to at least have startx print out a message (somewhere) which mentions the change when it is started up. Maybe print it out only once per userid. I realize that I am being a little vague with these suggestions, but I don't use X all that much, so I'm not sure what the best idea would be. But I do think it is reasonable for FreeBSD to make changes like this, and I do think that *if* we make changes like this then we need to think about how we can best get info about the change to the all people who really *are* effected by the change, and get the info to them when they need it. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ssh + compiled-in SKEY support considered harmful?
At 6:40 PM -0700 4/22/02, Peter Wemm wrote: Mike Meyer wrote: Jordan Hubbard [EMAIL PROTECTED] typed: My question: Who's wrong here, FreeBSD or Mac OS X? If the latter, Someone decided that FreeBSD should do challengeresponse authentication by default. You can fix it by uncommenting the line #ChallengeResponseAuthentication no in /etc/ssh/sshd_config. AHA! I've been wondering about this too. I cheated and set Protocol 1,2 to avoid the whole issue. The release notes at: http://www.FreeBSD.org/releases/4.5R/errata.html imply you can also fix this on the client side by adding the line: PreferredAuthentications publickey,password,keyboard-interactive to your own ~/.ssh/config file (useful if you need to connect to some machine where you can't change the /etc/ssh/sshd_config file). Usually I wouldn't know these things, but I just happened to be reading the errata notes a few minutes ago... :-) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ipcrm/shmctl failure
At 8:45 PM +1000 4/9/02, [EMAIL PROTECTED] wrote: Please don't make me use the kernel debugger... waa I believe Terry suggested: ...set the DISPLAY environment variable so that it uses a real network connection, instead of a UNIX domain socket (and thus allows the use of the MIT SHM extension). E.g., per the previous post: setenv DISPLAY `hostname`:0.0 I (personally would try that, and see what effect it had, before I would dive into a kernel debugger! Maybe it will have no effect, but even then you will at least have eliminated this issue from the discussion. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C-struct dismantling tool...
At 12:57 PM -0800 3/21/02, Julian Elischer wrote:
On Thu, 21 Mar 2002, John Polstra wrote:
I thought about the .stabs approach too, and thought it seemed
promising. Even better might be to use -gdwarf -g3, which in
theory at least would provide information about #defines.
For well-behaved structs, it's possible that rpcgen could be
hacked up to do what you want.
Sounds like a job for an objdump mutant.
Or write a C-program which prints offset(x) and sizeof(x) for
each field in the struct. It might not be too hard to write
a perl or ruby script which could generate such a program for
a given struct+include file. Here's a quick dirty example.
Perhaps someone C-smarter than I am could figure out how to
reliably add a column indicating if the variable is signed or
unsigned, integer or floating-point, plus any other interesting
characteristics. The tricky lines below are only tricky in
the sense that it would be tricky to get a script to *know* to
add the lines for those fields, such they are a sub-structure.
With a little more thought, it could also map out the struct,
indicating any bytes which were skipped over. Though it seems
to me there should be some way to get the compiler itself to
dump out something like this. I know I have seen that in some
non-C compilers, and I thought I had also seen it in some C
compilers...
/*
* Grungy little program to print out a stat structure.
* Garance/Mar 21/2002
*
* cc -Wall -o dumpstat.o dumpstat.c
*/
#include sys/stat.h
#include stddef.h
#include stdio.h
#define showheader(xStruct) {\
printf(Dump of '%s':\n, #xStruct);\
printf( offset size fieldname\n);\
}
#define showfield(xStruct,xVar) {\
indent = 1; \
for (cp = #xVar; *cp != '\0'; cp++) \
if (*cp == '.') indent += 2;\
printf( 0x%04lX %4lu%*s- %-1s\n, \
(unsigned long) offsetof(xStruct, xVar), \
(unsigned long) sizeof(((xStruct *)0)-xVar), \
indent, , #xVar);\
}
#define showtotal(xStruct) {\
printf(Total size = 0x%04lX aka %lu bytes)\n, \
(unsigned long) sizeof(xStruct), \
(unsigned long) sizeof(xStruct));\
}
int
main(int argc, char **argv)
{
const char *cp;
int indent;
showheader(struct stat);
showfield(struct stat, st_dev);
showfield(struct stat, st_ino);
showfield(struct stat, st_mode);
showfield(struct stat, st_nlink);
showfield(struct stat, st_uid);
showfield(struct stat, st_gid);
showfield(struct stat, st_rdev);
#ifndef _POSIX_SOURCE
showfield(struct stat, st_atimespec);
showfield(struct stat, st_atimespec.tv_sec);/* tricky */
showfield(struct stat, st_atimespec.tv_nsec); /* tricky */
showfield(struct stat, st_mtimespec);
showfield(struct stat, st_mtimespec.tv_sec);/* tricky */
showfield(struct stat, st_mtimespec.tv_nsec); /* tricky */
showfield(struct stat, st_ctimespec);
showfield(struct stat, st_ctimespec.tv_sec);/* tricky */
showfield(struct stat, st_ctimespec.tv_nsec); /* tricky */
#else
showfield(struct stat, st_atime);
showfield(struct stat, st_atimensec);
showfield(struct stat, st_mtime);
showfield(struct stat, st_mtimensec);
showfield(struct stat, st_ctime);
showfield(struct stat, st_ctimensec);
#endif
showfield(struct stat, st_size);
showfield(struct stat, st_blocks);
showfield(struct stat, st_blksize);
showfield(struct stat, st_flags);
showfield(struct stat, st_gen);
showfield(struct stat, st_qspare);
showtotal(struct stat);
return 0;
}
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Where are the TCP patches for 4.4?
At 2:48 PM -0800 3/8/02, Julian Elischer wrote: On Fri, 8 Mar 2002, Kenneth Culver wrote: If you want, I can make you some patches, I think I still remember when they went in... however I can't do any more than that... I'm sure I can get them, I'm just trying to find who it was that said they were compiling a set of good patches for 4.4 The only memory this triggers for me is: http://www.visi.com/~hawkeyd/freebsd-backports.html Is that what you're thinking of? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing -- anactual analysis of the code!
At 2:16 AM -0500 3/7/02, Brian T.Schellenberger wrote: Maybe your brain has gotten used to it, but to us ordinary mortals, even us ordinary mortals who've been slogging C code for time periods that can be measured in decades (yikes!), it is very tempting to read if (!strcmp(a,b,l)) as if the strings don't compare which, in ordinary usage, means don't compare *equal*. But of course the C program is going to proceed to do exactly the opposite of that. Okay, I will agree I have made that mistake a few times. Not often, but it really burns me up when I realize that's the source of some bug. So, that sounds like a good reason. But *ALL* of this is beside the nominal point ANYWAY, which is to discuss the proper wording for the man(9) style guide which is supposed to document how things things are actually done in the kernel, not personal preference. As to the wording, PHK suggested that the wording for this rule in style(9) be changed: - - - get rid of the word boolean, ie: change Do not use ! for tests unless it is a boolean, e.g. use to Do not use ! for tests unless it is an integer type, e.g. use - - - Dave O'Brien claimed the very same rule was *only* there to prevent if (!strcmp(a,b)). May I suggest that we probably want two different rules? Change the current rule so it says 'integer type' instead of 'boolean' (which doesn't really exist in C anyway), and then add the rule about strcmp()? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
In one message, At 12:52 AM -0800 3/6/02, David O'Brien wrote: I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. In a later message (not directly replying to the above), At 4:44 AM -0600 3/6/02, Mike Meyer wrote: Looking at the text in the page on -stable, I think the one-word change from boolean to integer would remove the ambiguity. If we change boolean to integer, then the proposed rule will not prevent if (!strcmp(a,b)) , because strcmp() *does* return an integer value. Or am I missing something here? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
At 7:49 PM +0100 3/6/02, Poul-Henning Kamp wrote: Garance A Drosihn writes: In one message, At 12:52 AM -0800 3/6/02, David O'Brien wrote: I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. If we change boolean to integer, then the proposed rule will not prevent if (!strcmp(a,b)) , because strcmp() *does* return an integer value. Or am I missing something here? Right, and since the integer is well defined, if (!strcmp(a, b)) is perfectly understandable so what is the problem ? Well, that's my question. David's comment implies that it is not good to do '!strcmp()', and I was wondering why it is not good... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
At 5:07 PM +0300 3/5/02, Eugene L. Vorokov wrote: Hello, I have a small problem. I work for software development company and write daemons and console tools for Unix. My boss wants everything to be written in C++, because he thinks C++ is cool. I prefer C for such tasks, but I cannot really put good arguments of why and where C++ can be worse than C. I know many of you prefer C too. Can you please explain some disadvantages of C++ comparing to C ? Anyone who thinks C++ is some kind of magic bullet because it is cool is just fooling themselves. You may be able to do some great stuff in C++, but only if you take the time to really learn the language, and it's pitfalls (so you know what to avoid). I prefer C over C++ because there is less there to really learn. but this is probably one of those personal-preference things which is impossible for any one side to prove their position to any other side... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: lpd filter stderr log files
At 3:16 PM +0100 2/15/02, Konrad Heuer wrote: Unfortunately, some changes in the lpd code that happened last year (as far as I remember) are very disadvantageous for the operation of our (heavily loaded) printer server which is based on FreeBSD for years now. Well, I'm willing to see what we can do to help you out. Prior to the changes, we could observe the progress of print jobs by a `tail -f /var/log/lpd-err/queue_log_file'. Now, all information written by the filter programs to stderr gets catched by temporary log files the names of which are created randomly. After a print job has completed, the contents of the temporary file is appended to the queue log file. Hmm. I suspect that any change there is more than a year old. We did change how the temporary-files were generated, but I think lpd has used temporary files for stderr for a long time. For our purposes, that's often too late. Why have these changes been made? And can the old behaviour be restored? I think the reason it's done this way (with the temporary files) is so multiple queues could point to a single log file, and so all the lines for any one job would be added onto that log file in one shot. I think there's a number of other reasons too. A quick look at the history for lpd/printjob.c seems to indicate that it has always behaved this way (or at least, it was always the *intention* that it behave this way, perhaps there were some bugs fixed). We really would like to see what happens during printing a job (imagine a 300 mb postscript print job which may a lot of time to execute completely). Well, here we see 1-gig postscript files going to our plotters, so it's pretty easy for me to imagine a 300-meg one... :-) It's obvious that you just changed to a new version of lpr. Did you also change any of your scripts? In some of my scripts, what I do is: exec 2$LPD_LOG_dir/$pname/log This causes the *script* to redirect stderr to where I want it. Would that work in your situation? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MAC address
At 4:10 AM +0300 2/9/02, Vladislav V. Anikiev wrote: Hello Brian, The MAC address - I meen The Media Access Control address (i.e., ethernet hardware address, not IP address). I want to use the default hardware (not current physical ) address in my license management software. Why did you write: Depending on the NIC. The NIC means Network Information Center. Doesn't it ? This is a case of TOL (TLA OverLoad)... (TLA = Three-Letter Acronyms) NIC can also mean Network Interface Card, and each card will (hopefully) have it's own unique MAC address. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Overriding ARG_MAX
At 10:54 PM -0500 1/4/02, David Miller wrote: What I usually want to do is something more like ls *.out |wc -l, or grep something *.data or cat *.foo | grep something. I have rebuilt the system in the past after greatly expanding ARG_MAX, and that does what I want. I'm just looking for an easy way to preserve it across cvsups, not looking for alternate ways to list the files in a directory:) While greatly expanding ARG_MAX might do what you want, it is a bad idea as there are a number of side-effects to doing that. You are not just fixing your problem, you are greatly increasing the memory usage of many things in the system -- some of which are going to assume the official POSIX setting for ARG_MAX (intentionally or unintentionally) no matter what you change it to. That is a mighty big hammer to swing to fix the problem you're talking about, and it's a hammer that you're going to have to keep expanding as you get more files to process. I doubt you'll be thrilled with this answer, as I am also going to ignore your direct question to answer what *I* consider to be the bigger question, but I would do this some other way. If it were me, I would write a script in perl or ruby which would do the operations I feel I need to do on these directories of files. Maybe I'd even generalize it, so I could feed it normal-looking commands, and the script would know how to break up the list of files to get the right results -- without going over ARG_MAX. This way you don't have to care about changing the size of ARG_MAX. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Oh my god, Google has a USENET archive going back to 1981!
Okay. Could we move the trip(s) down memory lane to some other mailing list? I'm certainly old enough to wax nostalgic about many things, but somehow freebsd-hackers doesn't seem to be an appropriate place to do that. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NFS Patch #4 -- survived overnight test. (was Re: Found NFSdata corruption bug... (was Re:...))
At 10:35 AM -0800 12/13/01, Matthew Dillon wrote: Are there still bugs in NFS? You bet! I'm sure there are bugs related to multiple clients and/or the server modifying files out from under a client, and I think the potential issue with nfsiod ordering that was posted to the list is a definite possibility. Perhaps the next round of torture-testing (after these are committed!) would be to have multiple clients running the program against a common NFS file server. But this should go a long way to improving the rock solid reputation of our stack! This is very excellent! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum ofdumped files
While on the topic of 'dump', note that there's also the patch in http://www.FreeBSD.org/cgi/query-pr.cgi?pr=bin/32414 which fixes a problem where dump will include information that should not be included (due to the nodump flag being set). This too would result in dump files larger than they should be... The PR includes a patch which is meant to fix this problem. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: wctype.h
At 2:54 PM -0600 12/3/01, Alfred Perlstein wrote: * Sergey Matveychuk [EMAIL PROTECTED] [011203 07:55] wrote: Hi! Why widechar functions is not implemented? Is there real difficulty? And can I get it somwhere from a external lib? I need towupper, towlower and iswspace. If you can provide sample code to verify the correctness of an implementation then i may be able to integrate it from netbsd. I thought we had some project which brought in the wide-character stuff, or at least was working on it. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD on vmware
At 7:35 AM -0800 11/15/01, John Baldwin wrote: On 15-Nov-01 Glenn Gombert wrote: Thanks for the tip Ian ...this works great! I have applied this patch to my desktop system ...and the FreeBSD Current kernel with this patch applied boots right up now...anyone else running Current under FreeBSD would fine it helpful to do as well Perhaps we need an 'options VMWARE' that this could be triggered off of. Sounds like a good idea. But call it something like 'VMWARE_GUEST', so it is less likely to be used by someone who wants to *run* vmware on freebsd. (and if we need some other kernel options for running vmware on freebsd, those could be called 'VMWARE_HOST', or something). -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: syslogd and kqueue
At 11:29 AM -0700 10/27/01, Terry Lambert wrote: Mike Barcroft wrote: I recommend using newsyslog(8) for rotating log files. I recommend _NOT_ using newsyslog for rotating files. The problem is that newsyslog doesn't rewrite history. As an example, say you have [...] Now you can only rotate it out with another 10K of data writtent to an already full /var (other log files are now free to consume the 10K you freed up), and then it will take 5 log rollovers before your /var is down to its proper disk utilization again, and your system is back to normal... and these can never happen. Until newsyslog is fixed to not be able to stage a denial of service attack against you, I really, really recommend against its use. Seems like it would be more user-friendly (to freebsd users in general) to fix newsyslog, instead of just telling people that they should not use it... If people just don't use newsyslog, how does that guarantee that whatever they do use will not have the same problem that you described? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: FYI
At 12:50 PM -0700 10/17/01, Jordan Hubbard wrote: I fully support your idea of offering a bounty to anyone writing drivers for your cards and think you're being more than generous in offering it. I wish more vendors would do that and I'm sorry that this discussion has gotten as polarized as it has. If people want to change the support situation for T1 cards, they need to get off their duffs and write the code - as a vendor, you're doing all that might be expected and more to facilitate the process. I hope the zealots in the audience realize that too. The freebsd project is really just a bunch of users who happen to use and work on freebsd. The group of users is such that we'll always PREFER a completely open-source BSD-licensed driver to other alternatives. However, it is also true that the vast majority of those users will prefer having a driver to NOT having a driver! :-) I think that offering some sort of bounty to have a freebsd developer work on drivers for your cards, under NDA, is a generous offer. I'm not the kind of person who writes drivers, but I certainly hope that someone takes you up on the offer. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: POSIX compatibility issue
I imagine Garrett and other standards-minded people have already seen this question, but I thought I'd echo it to the freebsd-standards mailing list. It's about a PR which makes a minor change to sys/types.h to solve some compile-time errors so that a program compiled with -D_POSIX_SOURCE currently gets if it references sys/socket.h. Seems like a plausible change to me, but I don't know enough about POSIX details to really know... At 11:22 PM -0700 9/5/01, Arun Sharma wrote: Can someone take a look at this PR ? http://www.freebsd.org/cgi/query-pr.cgi?pr=30317 It's necessary to fix compilation issues for a POSIX compliant Java VM, that uses sockets. There are similar open bug reports against NetBSD too, without any comments on why this change can not be made. -Arun -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
At 12:39 AM -0700 8/7/01, Mike Smith wrote: It also has the unfortunate property of locking us into virtual wire mode, when in fact Microsoft demonstrated that wiring down interrupts to particular CPUs was good practice, in terms of assuring best performance. Specifically, running in virtual wire mode means that all your CPUs get hit with the interrupt, whereas running with the interrupt bound to a particular CPU reduces the overall overhead. Even what we have today, with the big giant lock and redirecting interrupts to the CPU in the kernel is better than that... Terry, this is *total* garbage. Just so you know, ok? There are people on this list besides Terry. Terry has taken the time to refer to a few URL's, and remind us of a benchmark that I (for one) do remember, and I do remember Windows doing quite well on it. Maybe that benchmark was bogus for some reason, but I seem to remember several freebsd developers taking it seriously at the time. So, could you at least fill in what part of the above is total garbage? Throw in a few insults to Terry if it makes you feel better for some reason, but raise the level of information content a little for the rest of us? You quoted several distinct comments of Terry's -- were all of them garbage? It might very well be that all of Terry's comments were in fact garbage, but from the sidelines I'd appreciate a little more in the way of technical details. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
At 9:55 AM -0700 8/7/01, Matt Dillon wrote: : It also has the unfortunate property of locking us into virtual : wire mode, when in fact Microsoft demonstrated that wiring down : interrupts to particular CPUs was good practice, in terms of : assuring best performance. [...] : : Terry, this is *total* garbage. : : Just so you know, ok? : :What this, exactly? : :That virtual wire mode is actually a bad idea for some :applications -- specifically, high speed networking with :multiple gigabit ethernet cards? All the cpu's don't get the interrupt, only one does. :That Microsoft demonstrated that wiring down interrupts :to a particular CPU was a good idea, and kicked both Linux' :and FreeBSD's butt in the test at ZD Labs? Well, if you happen to have four NICs and four CPUs, and you are running them all full bore, I would say that wiring the NICs to the CPUs would be a good idea. That seems like a rather specialized situation, though. Okay, that's helpful to sort out the discussion. I'd agree that is a specialized situation, one which wouldn't be critical to many freebsd users. Is Terry right that the current strategy will lock us into virtual wire mode, in some way which means that this specialized situation CANNOT be handled? (it would be fine if it were handled via some specialized kernel option, imo. I'm just wondering what the limitations are. I do not mean to imply we should follow some different strategy here, I'm just wondering...) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to visit physical memory above 4G?
At 10:57 PM -0700 8/3/01, Terry Lambert wrote: Rik van Riel wrote: This is a trivial implementation. I'm not very impressed. Personally, I'm not interested in a huge user space, Maybe not you, but I bet the database and scientific computing people will be interested in having 64 GB memory support in this simple way. You mean 4G, of course, since the process address space remains limites to 32 bits... For what it's worth, we ran into some similar problem with a mainframe operating system I used to work on. We ended up creating something we called named address spaces for some user processes. Basically, it was just a quick swapping mechanism. In the context of IA-32, you could maybe have the first gigabyte of space as fixed, and the remaining three gigabytes as multiple (named) address spaces. Each named-address space could be between 1 and 3 gig, and you could have several of them. You'd make a system call to switch from one named-address space to a different one. It would not be practical for all user processes, but it would be useful for some of them. One ironic thing about this named-address space idea was that we had talked about it off-and-on for a few years, but we didn't actually *do* it until just as we were getting to the point where we could switch from 24-bit addressing to 31-bit addressing on our OS. We hit something where we just had to have the extra space right away (quicker than we could implement 31-bit addressing in userland processes). Once we decided to do this named-address space idea, it turned out it wasn't all that hard to implement. However, the current situation isn't quite the same as that one, and in the land of freebsd I'd think it would be better to concentrate on good support for the chips which do support 64-bit addresssing. I just thought it was worth pointing out that a process might well be limited to 32-bit addressing, and yet not be limited to 4-gig of usable memory space. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
