Re: SMP Version of tar
On Mon, Oct 08, 2012 at 08:38:33AM +0200, Wojciech Puchar wrote: gzip cannot - it is single stream. gunzip commutes with cat, so gzip compression can be multi-threaded by compressing separate blocks and concatenating the result. right. but resulting file format must be different. Not necessarily. If I understand correctly what Tim means, he's talking about an in-memory compression of several blocks by several separate threads, and then - after all the threads have compressed their respective blocks - writing out the result to the output file in order. Of course, this would incur a small penalty in that the dictionary would not be reused between blocks, but it might still be worth it. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? signature.asc Description: Digital signature
Re: mdoc(8) files (man files) editor?
On Wed, Sep 14, 2011 at 12:42:45PM +0400, Lev Serebryakov wrote: Hello, Hackers. What editor do you use for mdoc(8) / man files? Generic vi[m]/[x]emacs? Vim works just fine for me. Is here something special, maybe, kind of WYSIWYG? Constructs which starts at new line, like .Xr and .Nm make editing these files in generic-purpose text editor very uncomfortable, IMHO. Vim seems to automagically switch into 'nroff mode' and editing is actually quite nice and easy, IMHO. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I had to translate this sentence into English because I could not read the original Sanskrit. signature.asc Description: Digital signature
Re: setsid not found on freebsd
On Mon, Feb 14, 2011 at 12:32:21AM -0800, Garrett Cooper wrote: On Sun, Feb 13, 2011 at 11:46 PM, Ashish Mahamuni mahamuni.ash...@gmail.com wrote: I am using FreeBSD 8.1. I am doing some automation stuff and running shell scripts remotely using setsid command. It seems that I do not have setsid on my system. Also, searched in /usr/ports for installation but no luck. Could you please tell me the way to install this command or may be the alternative? It's a syscall, not an administrative command. How were you accessing it before? I believe that the original poster is referring to the setsid(1) command available in at least some Linux distributions; it's distributed as part of the util-linux-ng package and it basically does a fork(), setsid() and execve() to run a user-specified command as a session group leader in the style of daemon(8) (but without detaching or daemonizing :) I think it might not be too hard to implement it under FreeBSD. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am jealous of the first word in this sentence. signature.asc Description: Digital signature
Re: question about CFLAGS, CXXFLAGS and DEBUG_FLAGS
On Sat, Dec 18, 2010 at 09:24:31PM +, Alexander Best wrote:
On Sat Dec 18 10, Peter Pentchev wrote:
On Sat, Dec 18, 2010 at 08:09:37PM +, Alexander Best wrote:
hi there,
i just stumbled over these lines:
otaku% grep -n \${DEBUG_FLAGS} /usr/share/mk/bsd.prog.mk
24:CFLAGS+=${DEBUG_FLAGS}
25:CXXFLAGS+=${DEBUG_FLAGS}
is it really necessary to assign the debug flags to both CFLAGS *and*
CXXFLAGS?
Uhm... yes, so they can be used in both C and C++ programs :)
...or are you making the mistake I've made too many times (and still
make sometimes) of confusing CXXFLAGS with CPPFLAGS? :)
*hehehe* i don't think so.
Nah, just making sure, no offense intended :)
i just saw a lot of these lines in buildworld:
clang++ -O2 -pipe -DNDEBUG -g
-I/usr/obj/usr/subversion-src/tmp/legacy/usr/include
-I/usr/subversion-src/gnu/usr.bin/gperf/../../../contrib/gperf/lib
-I/usr/subversion-src/gnu/usr.bin/gperf -g -c
/usr/subversion-src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc
clang++: warning: argument unused during compilation: '-g'
clang++: warning: argument unused during compilation: '-g'
as you can see -g gets specified twice, so i thought maybe adding -g to
CFLAGS makes adding it to CXXFLAGS obsolete.
Well, according to my copy of src/share/mk/sys.mk (8.x-STABLE),
if the user does not override CXXFLAGS, they are copied from CFLAGS
with some exceptions. Thus, it does seem sensible to add -g to
both sets of flags - yes, if no CXXFLAGS are specified, the -g will
be doubled, but if CXXFLAGS *are* specified in the environment or on
the make(1) command line, then only one -g will be added.
Maybe a better solution could be to somehow test for empty CXXFLAGS
in sys.mk and set another variable that says we've copied those over,
and then only add DEBUG_FLAGS to CXXFLAGS if that variable is not set,
but I'm not sure if it's really worth it.
Thanks for bringing this up - I wasn't aware of the fact that CXXFLAGS
were copied over unless overridden :) Learn something new every day,
I guess.
G'luck,
Peter
--
Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
No language can express every thought unambiguously, least of all this one.
signature.asc
Description: Digital signature
Re: question about CFLAGS, CXXFLAGS and DEBUG_FLAGS
On Sat, Dec 18, 2010 at 08:09:37PM +, Alexander Best wrote:
hi there,
i just stumbled over these lines:
otaku% grep -n \${DEBUG_FLAGS} /usr/share/mk/bsd.prog.mk
24:CFLAGS+=${DEBUG_FLAGS}
25:CXXFLAGS+=${DEBUG_FLAGS}
is it really necessary to assign the debug flags to both CFLAGS *and*
CXXFLAGS?
Uhm... yes, so they can be used in both C and C++ programs :)
...or are you making the mistake I've made too many times (and still
make sometimes) of confusing CXXFLAGS with CPPFLAGS? :)
G'luck,
Peter
--
Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
Hey, out there - is it *you* reading me, or is it someone else?
signature.asc
Description: Digital signature
Re: Is it possible to have file removed upon process exit?
On Sat, Nov 27, 2010 at 08:16:54PM +0100, Dirk-Willem van Gulik wrote: Op 27 nov 2010, om 20:07 heeft Carlos A. M. dos Santos het volgende geschreven: On Sat, Nov 27, 2010 at 3:18 PM, Dimitry Andric d...@freebsd.org wrote: On 2010-11-25 21:14, Xin LI wrote: For certain applications it is sometimes desirable to (e.g. for unix domain sockets) have file removed when the process quit, regardless whether the process is quit cleanly. Is there a clean way to do this? Maybe your process could be the child of a parent which cleans up afterwards? (This is an analogy from real life. ;) Another option, depending on the situation is to fopen()/open() the file - and as soon as that is successfully done by all involved - have the creating process delete it. Errr... didn't the original poster also write the following? :) (admittedly, in a part that the follow-uppers skipped) One pretty common way of having an i-node of a file removed when process exit is to unlink() it while holding a descriptor of the file. This approach, however, have a side effect that other processes would not be able to access the file via its name. G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 You have, of course, just begun reading the sentence that you have just finished reading. signature.asc Description: Digital signature
Re: Improve OptionalObsoleteFiles.inc
On Mon, Oct 04, 2010 at 11:01:45AM +, Paul B Mahol wrote:
On 10/4/10, Alexander Leidinger alexan...@leidinger.net wrote:
Quoting Paul B Mahol one...@gmail.com (from Sun, 3 Oct 2010 13:53:26
+):
Hi,
diff --git a/tools/build/mk/OptionalObsoleteFiles.inc
b/tools/build/mk/OptionalObsoleteFiles.inc
index d3aa4b2..2123107 100644
--- a/tools/build/mk/OptionalObsoleteFiles.inc
+++ b/tools/build/mk/OptionalObsoleteFiles.inc
@@ -141,6 +141,7 @@ OLD_FILES+=usr/share/man/man8/authpf.8.gz
.endif
.if ${MK_BIND} == no
+OLD_FILES+=etc/periodic/daily/470.status-named
If bind is installed from ports instead, this file could be useful, isn't
it?
OLD_FILES+=usr/bin/dig
OLD_FILES+=usr/bin/host
OLD_FILES+=usr/bin/nslookup
[...]
@@ -1976,6 +1998,11 @@ OLD_FILES+=usr/share/man/man8/rtquery.8.gz
.endif
.if ${MK_SENDMAIL} == no
+OLD_FILES+=etc/periodic/daily/150.clean-hoststat
+OLD_FILES+=etc/periodic/daily/210.backup-aliases
+OLD_FILES+=etc/periodic/daily/440.status-mailq
+OLD_FILES+=etc/periodic/daily/460.status-mail-rejects
+OLD_FILES+=etc/periodic/daily/500.queuerun
OLD_FILES+=bin/rmail
OLD_FILES+=usr/bin/vacation
OLD_FILES+=usr/include/libmilter/mfapi.h
At least status-mailq is still useful with other MTAs, e.g. if you use
postfix (and assuming the mailwrapper is configured correctly), this
should still work. Depending on the setup of the aliases,
backup-aliases will still work too. I haven't checked for the other
ones.
If you want to keep some old files, you just need to press `n' instead of
`y'
when deleting files. You are not forced to run make delete-old at all.
On the other hand, doing this (skipping those files) on each and every system
update (say, on a development or testing machine) could get a bit... boring -
not to mention that at some point you'll learn to oh, just say no, and then
forget to remove something important.
G'luck,
Peter
--
Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
Do you think anybody has ever had *precisely this thought* before?
signature.asc
Description: Digital signature
Re: How to disallow logout
On Fri, Sep 10, 2010 at 10:30:35PM -0400, jhell wrote: On 09/10/2010 22:21, jhell wrote: On 09/09/2010 23:27, Aryeh Friedman wrote: I have a directory that must not exist on logout and rm -rf is not sufficent to do it because the contents need to be processed by our version control system. The real life scenario is our version control system stores the repo for a given project encrypted but for techinical reasons it needs to keep the checkouted files in plain text (they are all in the same dir) and I want to *NEVER* have the plain text checkouted files in my dir when I logout, *BUT* instead of just deleting it I need to check them in... so how do I make my .logout so if the file exists it will not exit and give a error saying that dir is still there? (minor but unimportant side effect of the version control system is the dir will have a different name everytime it is made but always the same prefix) ___ 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 trap '/path/to/your_wrapper_script.HERE' 2 This should be: trap '/path/to/script' EXIT Should execute the contents of that script on every logout. Whether that script is a line by line action or a fully qualified script with functions to call different actions are up to you. ...but, of course, that's only until people learn that they can bypass this by something like 'kill -FPE $$'. G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If wishes were fishes, the antecedent of this conditional would be true. signature.asc Description: Digital signature
Re: an alternative to powerpoint
On Tue, Jul 13, 2010 at 06:15:14AM +0200, Luigi Rizzo wrote: Maybe you all love powerpoint for presentations, but sometimes one just needs to put together a few slides, perhaps a few bullets or images grabbed around the net, so i was wondering how hard would it be to do something that accepts a plain text file as input (without a ton of formatting) and lets you do a decent slide show, and supports editing the slides on the fly within the browser. Well, it's not too hard: http://info.iet.unipi.it/~luigi/sttp/ just 400 lines of javascript and 100 lines of css, plus your human-readable text. Nice work indeed! Just as an aside, though - are you aware of Eric Meyer's S5, also available in your friendly neighbourhood Ports Collection as textproc/s5? :) But yours does look a bit simpler to enter text in, although I myself am quite used to typing HTML. G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence would be seven words long if it were six words shorter. signature.asc Description: Digital signature
Re: using cupsd instead of base lpr
On Thu, Jun 24, 2010 at 03:56:56PM +0200, Dag-Erling Smørgrav wrote: Ed Schouten e...@80386.nl writes: In my opinion, we should just rename mailwrapper to whateverwrapper and list the lpr programs in there as well. Take a look at /etc/alternatives in any Debian-based Linux distro... Yeah, that's actually something I've long wondered about implementing; shouldn't be too hard, really. Never found the tuits, though :) For those who don't know what the idea is: /usr/bin/ftp is a symlink to /etc/alternatives/ftp, which in its turn is a symlink to /usr/bin/tnftp. The /etc/alternatives/ links are maintained by the update-alternatives utility which knows about priorities, defaults, slave symlinks (e.g. if the ftp(1) utility's symlink changes, it would be best to also change the ftp.1.gz manpage symlink, wouldn't it?), and a whole lot more. From a user's standpoint, all you have to do is install a package that declares a higher-priority alternative, and update-alternatives switches the symlink behind the scenes (unless you have explicitly specified one of the choices). If you don't like that, run update-alternatives by hand, and your choice is honored even if later a package with an even higher priority is installed. G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? signature.asc Description: Digital signature
Re: Are POSIX mqueues supposed to be functional on FreeBSD?
On Sun, Jun 20, 2010 at 03:02:35PM -0700, Garrett Cooper wrote: Err... I ran an mqueue test and it popped up with ENOSYS. Which makes me wonder, are POSIX mqueues implemented 100% on FreeBSD? I looked into sys/kern/uip_mqueue.c and it _appears_ functional, but I could be misreading the code. Another test written which tests mqueue appears to be broken as well (I'll include that in a later email if interested). I also attached the truss output and the relative code blurb for a little more analysis. Thanks, -Garrett PS I'm not guaranteeing that the code below doesn't have bugs in it as I'm not the original author and the tests were originally written and targeted towards Linux. Do you have the P1003_1B_MQUEUE option in your kernel config? G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. signature.asc Description: Digital signature
Re: GSoC: Making ports work with clang
On Sun, May 02, 2010 at 11:51:52PM +0300, Andrius Mork??nas wrote: On Sun, 02 May 2010 10:25:22 +0300, Yuri y...@rawbw.com wrote: Having tried clang++ I have a feeling that it's not quite ready to be a generic c++ compiler. [snip] Very immature. Many problems that C++ ports have with clang is not related to it being immature, they're related to the fact that clang isn't gcc and that those ports aren't written in standard C++. Too true. [snip] You will just keep stumbling upon various problems with various ports I've mentioned that I've been involved with ports+clang since last October. Stumbling upon various problems is what I do. I'm still here, even doing a GSoC project, so it doesn't look like various problems will scare me off. And as I've mentioned above, just because some ports don't compile, it doesn't affect this project too much. Well said, well meant. Kudos. Thanks for your work so far, and thanks for taking up that GSoC project. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 I am the meaning of this sentence. pgpoRO1eWZrzy.pgp Description: PGP signature
Re: Modifying ELF files
On Thu, Apr 08, 2010 at 07:17:46AM -0700, Patrick Mahan wrote: In my job, we are producing applications and KLM's for our product that require them to be signed so that our installer will recognize and validate our images. The signature is stored in each app as unsigned char signature[40] __attribute__((section(.compsign))); What I need to do is open the file for writing, locate the .compsign section and stuff in the signature, write it out and close the file. (simple ELF manipulation) An 'ls -l' shows the following: % ls compklm.ko -rw-r--r-- 1 pmahan pmahan 125296 Apr 6 22:50 /home/pmahan/temp/compklm.ko When I try to run my program ./signfile --signature=A203239897C8EB360D1EB2C84E8E77B16E5B7C9A compklm.ko open: Text file busy Googling and looking at the kernel sources, it seems that it detects this file contains 'shared text', that is, it is an executable file and does not allow me to open it for writing. I understand (from my google search) this is a means to keep you from shooting yourself in the foot. But there has got to be a way and I really don't want to grovel through the compiler code to find it. I looked at using libelf.so but it also requires that the file be open for writing. So I am kinda of stuck. If I cannot find a quick solution we might need to do all of our signing on our FC11 box which does not have this issue. It's not the compiler code you want to find it, but the install(1) program that is used to, well, install files into e.g. /bin, /usr/bin, etc. What it does is create a temporary file in the directory where it wants to place the final file, write into the temporary file, and then, when the file is complete and only when it is complete, it does a rename(2) syscall, moving the temporary file over the real one. If a program (or the kernel) is using the old version of the real file, its inode and its data blocks are still present on the disk and they are only deleted when the last consumer closes the file (or rather, the file descriptor it's holding on that inode). This also guarantees that anyone who tries to open the file will only open it when it's ready, and will not try to execute a partially-written-out executable or something. So, what you need to do if you want to modify a file is create a new one in the same directory (well, it's really on the same filesystem, but the most portable way to ensure that is to use the same directory - unless you require from the user to specify a temporary directory you can use on the same filesystem). Then, read the original file, write into the new one, and when you're ready, do a rename(tempfile, realfile). Hope that helps. G'luck, Peter -- Peter Pentchev r...@space.bgr...@ringlet.netr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 signature.asc Description: Digital signature
Re: [RFC] The official logo for logo_saver?
On Wed, Apr 07, 2010 at 09:18:09AM +0200, Dag-Erling Sm??rgrav wrote: Jung-uk Kim j...@freebsd.org writes: Although I really like logo_saver with Beastie, we have the official FreeBSD logo and I think it is time to say good-bye to the old logo image file. The attached file is a drop-in replacement for sys/dev/syscons/logo/logo.c. What do you think? I agree, please commit. Mmm, not to belittle jkim's work in any way (thanks for taking the time!), but... I wonder if this could somehow be made optional - TBH, I really like the current/old/original logo_saver image :) Of course, the new one is nice, too, and also official, but I still like the old one just a little bit better :) Maybe keep both arrays in the file and have a sysctl or something? (yes, I know there are people who think that there are already too many sysctl's and new ones shouldn't be added for trifles, but still... :) G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. pgpqKduX5MVPi.pgp Description: PGP signature
Re: Wine on amd64 in 32 bit jail
On Mon, Nov 23, 2009 at 12:11:02AM -0500, Dylan Cochran wrote: On Sat, Nov 21, 2009 at 5:52 AM, Peter Jeremy peterjer...@acm.org wrote: I did run into problems initially because my i386 userland wasn't aligned with my amd64 kernel but rebuilding both fixed that (I'm running 8.0-RC1 and a bit). Note that some tools that poke around in kernel innards won't work - ps and lsof are the most obvious. ktrace works but the resultant ktrace.out files need to read with an amd64 kdump. A word of caution: not all the ioctl's and setsockopt's have the proper glue code under COMBAT_FREEBSD32... That was actually a nice typo :P G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 This sentence would be seven words long if it were six words shorter. pgptwi6U2AKJJ.pgp Description: PGP signature
Re: Transferring ports
On Fri, Mar 14, 2008 at 12:02:42AM +0300, Dmitry Marakasov wrote:
* Ivan Voras ([EMAIL PROTECTED]) wrote:
Is there a utility that would do that, and if not, does anyone have the
time to write one?
Actually, I've already had an idea of utility with pretty similar
functionality for a long time. The utility would copy directory
hierarchies recursively based on file include/exclude list, like this:
+/{etc,bin,sbin,lib}
+/usr
-/usr/local
+/usr/local/{bin,sbin,libexec,share,lib}
-/usr/share/locale
+/usr/share/locale/ru_RU*
so `my_cool_copy_utility / /path/to/jail` will copy /etc,/bin,/sbin,/lib
and /usr dirs to jail, but in /usr/share/locale will only copy
russian locales, but no others, and in usr/local it won't copy
man, include and other dirs not needed in a jail.
The purpose is similar - creating jails out of host system in fast
and easy way, possibility to strip everything unneeded (useful for
secure minimal jails or flash/livecd/embedded installations of
minimal size) and add something extra, like stuff from /usr/local
without installing full packages in a jail, or, say, copying over
additional tree of jail-specific changes (mostly stuff under /etc
and /usr/local/etc).
Such an utility is something I still might start working on.
Err... why not use rsync for that? It works locally, too -
I use it to copy directories all over the place all the time.
Come to think of it... oh, just go install net/rsync, take a look at
its manual page and the FILTER RULES section in particular - it even
supports rules with prefixes, - for exclude, + for include, just
like you want them :) Well, okay, you might need to list separate
directories on separate lines (it doesn't seem to support the {bin,sbin}
syntax), but other than that, it seems to fit your requirements pretty
well :)
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This sentence claims to be an Epimenides paradox, but it is lying.
pgpHVw3fpalLG.pgp
Description: PGP signature
Re: ELF binary type 0 not known.
On Fri, Sep 16, 2005 at 11:56:09AM +, Wouter van Rooij wrote: I have this error message when i'm wanting to start mozilla for example. Do some of you know whats wrong and what I can do to get it working again? Is this a Linux binary of Mozilla? If you are trying to run a Linux application, you need to do three things: 1. Install a Linux emulation port - ports/emulators/linux_base is a good choice; 2. Load the linux.ko kernel module or compile it into the kernel; 3a. Set the kern.fallback_elf_brand sysctl variable to 3, or 3b. Run 'brandelf -t Linux /path/to/executable' on the file that you want to actually run. For more information, see chapter 10, Linux Binary Compatibility, of the FreeBSD Handbook. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This would easier understand fewer had omitted. pgpUlpe2mVo18.pgp Description: PGP signature
Re: ELF binary type 0 not known.
On Fri, Sep 16, 2005 at 11:07:31PM +0930, Daniel O'Connor wrote: On Friday 16 September 2005 22:53, Peter Pentchev wrote: On Fri, Sep 16, 2005 at 11:56:09AM +, Wouter van Rooij wrote: I have this error message when i'm wanting to start mozilla for example. Do some of you know whats wrong and what I can do to get it working again? Is this a Linux binary of Mozilla? If you are trying to run a Linux application, you need to do three things: 1. Install a Linux emulation port - ports/emulators/linux_base is a good choice; 2. Load the linux.ko kernel module or compile it into the kernel; 3a. Set the kern.fallback_elf_brand sysctl variable to 3, or 3b. Run 'brandelf -t Linux /path/to/executable' on the file that you want to actually run. For more information, see chapter 10, Linux Binary Compatibility, of the FreeBSD Handbook. Or.. cd /usr/ports/www/linux-mozilla make install :) (or firefox, or..) Yep, I think this probably takes care of step 1 and possibly 3b, although the message that Wouter gets is making me think that for some reason the port has *not* run brandelf on the executables - if brandelf had been run, wouldn't the error message mention ELF binary type 3, not 0? So I went ahead and included all the steps, just to cover all bases :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? pgpLZE82LeuNz.pgp Description: PGP signature
Re: ELF binary type 0 not known.
On Fri, Sep 16, 2005 at 11:57:21PM +0930, Daniel O'Connor wrote: On Friday 16 September 2005 23:42, Daniel Eischen wrote: I'd be *very* suprised.. I expect he just downloaded an RPM from somewhere.. It's probably just not having linux.ko/linprocfs.ko loaded. $ kldstat Id Refs AddressSize Name 11 0xc040 498518 kernel $ /usr/compat/linux/bin/ls ELF binary type 0 not known. $ sudo kldload linux.ko $ kldstat Id Refs AddressSize Name 15 0xc040 498518 kernel 21 0xc2a1a000 16000linux.ko $ /usr/compat/linux/bin/ls /bin basename chgrp cpecho fgrep ls mvrm setserial stty true bash chmod date egrep grep mkdir nice rmdir sh sync uname bash2 chown ddfalse ln mknod pwd rpmsleep touch Wow that's weird.. I wonder why that happens? What is weird? The fact that if linux.ko is not loaded, the kernel does not know what to do with an unknown ELF binary type? :) What I find weird is the fact that as soon as linux.ko is loaded, the kernel learns to treat type 0 binaries as type 3; but this is probably because Daniel Eischen has at some earlier time set the kern.fallback_elf_brand sysctl to 3. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. pgpxXtTF3t4Eu.pgp Description: PGP signature
Re: fok() execve() - No child processes
On Thu, Sep 08, 2005 at 12:40:20PM -0700, erkan kolemen wrote:
Following code fails. I debugged it and saw that: it
produces No child processes error while wait().
is it possible, parent still is not start to wait but
child finished. After that CPU schedules parents. It
try to start wait but child has finished.
is it possible... What can i do for that?
[snip]
default:
if (wait(stat) == -1) {
slog(1, LOG_ERR);
return -14;
}
Just an idea: what happens if you try waitpid(pid, stat, 0) instead
of wait(stat)?
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
I've heard that this sentence is a rumor.
pgpgY22C3LxXB.pgp
Description: PGP signature
Re: How to reset root passwd FreeBSdD4.7
On Fri, Jul 15, 2005 at 09:44:35AM +0300, Vasil Dimov wrote: On Thu, Jul 14, 2005 at 09:55:16AM -0400, John Von Essen wrote: Boot with 1st CD, goto the Fixit Shell (will need 2nd CD). From there you have to manually mount the / filesystem and edit passwd (just clear out the passwd, root::). However, do an fsck on the device first (you may have to reboot afterwards) since if you have any fragmentation following an unclean shutdown, you will not be able to mount the device. Simply editing /etc/passwd won't do the work (this is not Linux, eah) /etc/master.passwd must be edited and then pwd_mkdb /etc/master.passwd must be run. Much easier to just chroot(8) into the mounted filesystem and use the 'passwd root' command, as others have already suggested - after booting from the fixit CD, of course. [Cc list snipped, eek] G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 The rest of this sentence is written in Thailand, on pgpZnxdnxanaO.pgp Description: PGP signature
Re: ABV.BG автоматичен отговор
On Tue, Mar 29, 2005 at 07:53:34PM -0500, c0ldbyte wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 30 Mar 2005 freebsd-hackers@freebsd.org wrote: blagodarq za izpratenoto ot Vas pismo nai skoro shte vi otgovorq!! Can you guys at (Headquarters) turn the above auto reply off. By god it is not even readable. There's pretty much nothing the guys at FreeBSD.org can do, except maybe find out which of the @abv.bg addresses subscribed to the lists generates this autoreply and unsubscribe it. ABV.BG is a widely-used Bulgarian free webmail service; apparently they have misconfigured their autoresponse setup very badly recently (including the faking of a sender address for no apparent reason at all), since I've seen similar complaints on several lists totally unrelated to FreeBSD.org. As to the response itself, it says 'thank you for the letter you sent; I'll respond as soon as possible'. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I've heard that this sentence is a rumor. pgpj4NUQOkBIG.pgp Description: PGP signature
Re: passwd permissions
On Wed, Mar 23, 2005 at 11:41:13AM -0600, H. S. wrote: [snip] Since pw is not setuid, if it can't read any of the passwd files, it will not print the full userlist. I have very customized (and tested, over the years) permissions on the whole filesystem. That is why I wanted to find out why some permissions get back to system defaults whenever I install a port. The most proeminent cases are /usr/local/sbin/ (gets back to rwx rx rx) and /usr/local/www (rwx rx rx and chgrp wheel, I have a different group owning the directory). Any idea about what to fix in order to make the system stop resetting my permissions when I install ports ? The mtree(8) file for the /usr/local hierarchy, found in /etc/mtree/BSD.local.dist G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence contains exactly threee erors. pgp0neIyYVPhr.pgp Description: PGP signature
Re: clock.h
On Mon, Feb 28, 2005 at 11:39:52PM +0800, Kathy Quinlan wrote: I have this: #include machine/clock.h In program I use this: DELAY(1000); I get this: undefined referance to 'DELAY' when I compile the program with GCC with flags -Wall -g -o com main.c ANY ideas ?? I have looked in the relevent header and it seems to be there Yes, it is in clock.h, but... /*- * Kernel interface to machine-dependent clock driver. That's the way that clock.h starts. The 'kernel interface' part means that this is a header file that declares functions that are used *only* within the FreeBSD kernel - since they are only implemented in another part of the kernel code. You cannot use these definitions and functions from a userland program, as you are trying to do. The reason that the DELAY() declaration seems to be in the header file, yet the compiler does not see it, is the #ifdef _KERNEL at the top of clock.h :) This is just a level of protection that accomplishes exactly that - no userland program should *ever* define the _KERNEL symbol, so no userland program will be fooled into believing that there is a DELAY() function that it could possibly use. It simply cannot, since the DELAY() function is declared within kernel code for use by the kernel only. If you want a high-precision delay/sleep interface in a userland program, take a look at the usleep(2) and nanosleep(2) syscalls. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the meaning of this sentence. pgp33T3UcsqGT.pgp Description: PGP signature
Re: SIGBUS help, please
On Sun, Feb 13, 2005 at 10:03:30AM -0500, Brian Fundakowski Feldman wrote: On Thu, Feb 10, 2005 at 10:55:58PM +0200, Ion-Mihai Tetcu wrote: Hi, One of my ports - mail/dspam-devel stays at 3.4 because newer versions crash on FreeBSD (they work on Linux and Solaris). Can someone make some sense from the output bellow ? I'm willing to make a port and help with all needed setup information - a 5-10 minutes job if someone has the time for it. Have you tried valgrind in any of its modes yet? Wasn't some valgrind output included in the message you actually replied to? :) Or am I misunderstanding your question due to the fact that I've never actually used valgrind? If so, sorry... G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Nostalgia ain't what it used to be. pgpPZXsELWPhY.pgp Description: PGP signature
Re: How many developers?
On Thu, Feb 10, 2005 at 05:02:04PM +0300, Maxim Konovalov wrote:
On Thu, 10 Feb 2005, 14:53+0100, Ivan Voras wrote:
For statistical purposes, where can I get information such as the number of
developers (with commit bit?) active on the FreeBSD project?
cvs co -p CVSROOT-src/access CVSROOT-doc/access CVSROOT-ports/access \
2/dev/null | grep -v ^# | awk '{print $1}' | sort -u | wc -l
Surely you mean awk '!/^#/ {print $1}' ;)
Nahh, I don't need a coat, it's just -17C outside...
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
What would this sentence be like if pi were 3?
pgpnDk6CDKOJb.pgp
Description: PGP signature
Re: Opening and wriiting to file in Kern
On Sun, Feb 06, 2005 at 04:22:41AM -0800, Kamal R. Prasad wrote: --- Scott Long [EMAIL PROTECTED] wrote: Ashwin Chandra wrote: Does anyone know the correct calls to open a file, write to it, and close it, IN *kernel* mode. Ash There is no common API for doing this, which is pretty much on purpose. First, you need to ask yourself why your task needs it done in the kernel and not in userland. A feature implemented within the kernel that requires making stuff persistent would almost certainly require file I/O. For that matter, a kernel (module) that reads a configuration file will also need the same facility. I don't see anything wrong with providing a stream (like) interface to the filesystem. While there might indeed be nothing wrong with it, besides added complexity, the traditional way to do it would be to have a userland configuration utility that communicates with the kernel module either via ioctl's on some standard device, or via ioctl's or reading/writing of a driver-specific device. This has the advantage of being a bit more portable - while different OS's implement disk/file I/O within the kernel in wildly different ways, all OS's provide relatively simple ways for a kernel module to define a new device and handle ioctl's to it, and all OS's provide basically the same userland-to-kernel interface for having a program open a device and issue ioctl's to it :) Another way would be, again, communication between a userland utility and a kernel module, but this time using mmap'd files/devices instead of ioctl's. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence was in the past tense. pgpIe37hBohxn.pgp Description: PGP signature
Re: GNUstep and libkvm
On Sun, Jan 23, 2005 at 01:17:31AM -0800, Pascal Hofstee wrote: OOpps .. forgot to actually attach my kvmtest. It didn't make it through this time, either. Note that the FreeBSD mailing list manager rejects attachments of certain types, so if you are sending a C source file as, say, application/octet-stream, it *will* be stripped from the message before it makes it to the list. Best use text/plain for patches and source files. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? pgp2PMI1gi5a2.pgp Description: PGP signature
Re: Freeing Volatile Pointer
On Mon, Jan 03, 2005 at 06:09:45PM +0530, Tejas Sumant wrote: Hi, I have a volatile pointer declared in my device driver. I am allocating memory using kernel malloc function. host_mem_resp_ptr = (volatile unsigned long *)malloc(sizeof(volatile unsigned long), M_DEVBUF, M_NOWAIT); When I try to free it, I get following warning while compiling the driver. warning: passing arg 1 of free discards qualifiers from pointer target type The statment to free the memory is free(host_mem_resp_ptr, M_DEVBUF); Can anybody please tell me reason and solution? The reason is that the C compiler treats 'void *' and 'volatile void *' as different types. In this case, the compiler casts your 'unsigned long *' to 'void *' and still warns you that this might not necessarily be what you want, although it is harmless in this case. In theory, if a function is declared as accepting a non-volatile pointer, passing a volatile pointer could be dangerous - the function could stash it somewhere and then attempt to reuse it later when its value has actually been changed. This might cause the function to access memory that is no longer allocated, or just the wrong chunk of memory, or something similar. In your case the only danger lies in some other thread modifying the pointer *and invalidating the memory* that it previously pointed to, after you call free() and before free() has actually freed the memory. It is up to you to decide whether this is a risk - or rather, to make sure that it isn't :) Then use something like: free((void *)host_mem_resp_ptr, M_DEVBUF) ...and you should be okay, unless you specifically pass -Wcast-qual to the compiler. If you do, it will again give this warning, just because you have explicitly asked it to :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? pgpURRI6e14Hi.pgp Description: PGP signature
Re: Creating Compressed Loop FS from stdin
On Wed, Dec 29, 2004 at 11:15:40PM +0100, Matteo Riondato wrote:
Hi folks!
I think you know what FreeSBIE
is and that we use compressed loop filesystems for /usr and /var
directories on our LiveCD.
At the moment, to create compressed filesystems, we rely on
sysutils/cloop-utils, but I know /usr/bin/mkuzip is present in HEAD and
in RELENG_5 and would like to switch to that. However, it seems that I
cannot create valid cloopfs with mkuzip.
To create the cloop image, I use:
/usr/local/bin/mkisofs -lrJL $FREESBIEBASEDIR/usr | /usr/bin/mkuzip -v \
-o $FREESBIEBASEDIR/cloop/usr.cloop -s 65536 /dev/stdin
Well, as you can see from the very first line output by mkuzip in that
case (if -v is indeed specified), it thinks that the input file is 0 bytes
long. This is so because the first thing mkuzip does is a stat(2) on
the input file descriptor, and when you point it at /dev/stdin, stat()
returns a length of 0 bytes since it is impossible to determine beforehand
how much data will be produced by the pipe.
This could be fixed by the following patch. I'm CC'ing Maxim Sobolev,
the author of mkuzip(8); Maxim, do you have any objections to this patch?
G'luck,
Peter
Index: src/usr.bin/mkuzip/mkuzip.c
===
RCS file: /home/ncvs/src/usr.bin/mkuzip/mkuzip.c,v
retrieving revision 1.2
diff -u -r1.2 mkuzip.c
--- src/usr.bin/mkuzip/mkuzip.c 10 Sep 2004 23:16:05 - 1.2
+++ src/usr.bin/mkuzip/mkuzip.c 30 Dec 2004 10:32:38 -
@@ -122,10 +122,23 @@
signal(SIGXFSZ, exit);
atexit(cleanup);
- if (stat(iname, sb) != 0) {
+ fdr = open(iname, O_RDONLY);
+ if (fdr 0) {
err(1, %s, iname);
/* Not reached */
}
+
+ /* Try seeking to the end; if that fails, fall back to fstat() */
+ sb.st_size = lseek(fdr, 0, SEEK_END);
+ if (sb.st_size 1 fstat(fdr, sb) != 0) {
+ err(1, %s, iname);
+ /* Not reached */
+ }
+ if (sb.st_size 1) {
+ errx(1, Could not determine the size of %s, iname);
+ /* Not reached */
+ }
+ lseek(fdr, 0, SEEK_SET);
hdr.nblocks = sb.st_size / hdr.blksz;
if ((sb.st_size % hdr.blksz) != 0) {
if (verbose != 0)
@@ -135,11 +148,6 @@
}
toc = safe_malloc((hdr.nblocks + 1) * sizeof(*toc));
- fdr = open(iname, O_RDONLY);
- if (fdr 0) {
- err(1, %s, iname);
- /* Not reached */
- }
fdw = open(oname, O_WRONLY | O_TRUNC | O_CREAT,
S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
if (fdw 0) {
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This sentence claims to be an Epimenides paradox, but it is lying.
pgpFfxLg3fluR.pgp
Description: PGP signature
Re: Creating Compressed Loop FS from stdin
On Thu, Dec 30, 2004 at 01:28:28PM +0100, Matteo Riondato wrote: Il giorno Gio, 30-12-2004 alle 12:34 +0200, Peter Pentchev ha scritto: This could be fixed by the following patch. I'm CC'ing Maxim Sobolev, the author of mkuzip(8); Maxim, do you have any objections to this patch? Thank you for the answer and fo the patch! I hope Maxim will commit it soon. Actually, if Maxim has no objections, I could commit it myself. However, it would be totally understandable if he doesn't answer in the next day or three, what with the calendar moving ahead and all :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If this sentence didn't exist, somebody would have invented it. pgpSQ6T6MKQq1.pgp Description: PGP signature
Re: Support for Adaptec Ultra 320 (29320)
On Thu, Dec 30, 2004 at 09:53:49AM -0300, [EMAIL PROTECTED] wrote: Hi everyone ! I hope all had a nice Xmas and I wish a happy new year to you all !! I?m not sure I saw this issue here before but is there support for the Adaptec Ultra 320 (29320) scsi controller on FreeBSD 5.3 ? I know it is a new controller. According to the CVS history of the src/sys/dev/aic7xxx/ahd_pci.c file, the 'ahd' driver (which supports Adaptec Ultra 320) was added to FreeBSD about two and a half years ago :) http://cvsweb.FreeBSD.org/src/sys/dev/aic7xxx/ahd_pci.c G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. pgp0BQ3MAUn0F.pgp Description: PGP signature
Re: Support for Adaptec Ultra 320 (29320)
On Thu, Dec 30, 2004 at 11:54:07PM +1100, Edwin Groothuis wrote: On Thu, Dec 30, 2004 at 09:53:49AM -0300, [EMAIL PROTECTED] wrote: Hi everyone ! I hope all had a nice Xmas and I wish a happy new year to you all !! I?m not sure I saw this issue here before but is there support for the Adaptec Ultra 320 (29320) scsi controller on FreeBSD 5.3 ? 5.3? yes. According to the CVS history of the ahd_pci.c file (URL mentioned in my other reply), the 'ahd' driver is supported not only in 5.3, but also in 5.2.1, 5.2, 5.1, 5.0, and actually all the way back to 4.7 :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If you think this sentence is confusing, then change one pig. pgpvXWHvhHNr8.pgp Description: PGP signature
Re: Creating Compressed Loop FS from stdin
On Thu, Dec 30, 2004 at 03:32:27PM +0200, Maxim Sobolev wrote: Peter Pentchev wrote: On Thu, Dec 30, 2004 at 01:28:28PM +0100, Matteo Riondato wrote: Il giorno Gio, 30-12-2004 alle 12:34 +0200, Peter Pentchev ha scritto: This could be fixed by the following patch. I'm CC'ing Maxim Sobolev, the author of mkuzip(8); Maxim, do you have any objections to this patch? Thank you for the answer and fo the patch! I hope Maxim will commit it soon. Actually, if Maxim has no objections, I could commit it myself. However, it would be totally understandable if he doesn't answer in the next day or three, what with the calendar moving ahead and all :) It will not help, since AFAIK you can't seek stdin anyway, or even if I am wrong and you can seek it to the end you will be unable to seek it backward. I tested the patch before posting it, fully expecting to find that stdin really cannot be seeked (sought? :), and surprisingly it worked, at least on RELENG_5 as of today! I've already replied to this message, but Matteo has some very strange settings of his smtp relay so that neither my original message nor my follow-up in which I had forwarded mail delivery error message got through. -Maxim Original Message Subject: Re: Creating Compressed Loop FS from stdin Date: Fri, 17 Dec 2004 17:14:48 +0200 From: Maxim Sobolev [EMAIL PROTECTED] Organization: Porta Software Ltd To: Matteo Riondato [EMAIL PROTECTED] References: [EMAIL PROTECTED] This is not going to work by design unfortunately. cloop format has serious design flaw: it contains variable-lengh header at the beginning of the compressed image, so that before doing compression mkuzip(1) uses stat(2) call at the original file to get its size and reserve necessary space, which doesn't work with /dev/stdin as you may guess. Original GNU utility either keeps the whole compressed image in memory or uses some form of temporary storage (I don't quite remember) to work around this problem. Well, another solution would be to make mkuzip use a temporary file (obviously, keeping the whole thing in memory would be a bad idea for big ISO filesystems ;). However, as I noted above, my lseek patch works at least for RELENG_5. Can somebody test it on -CURRENT? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This inert sentence is my body, but my soul is alive, dancing in the sparks of your brain. pgpsUZMsPR7Tz.pgp Description: PGP signature
Re: Creating Compressed Loop FS from stdin
On Thu, Dec 30, 2004 at 04:20:16PM +0200, Maxim Sobolev wrote:
You don't check return code of the second lseek - I bet it fails. This
probably leads to creation of seemingly valid loop fs (i.e. with valid
header), but filled with zeroes or some random junk.
I said I'd tested it before posting it the first time. It works.
It creates a valid loop fs, containing exactly the files that are in
the input ISO image.
However, your point is valid; here's another patch which returns to the
start only if the original lseek() did not move away (or failed), and
checks the return value, too. This version of mkuzip works on today's
RELENG_5, as can be seen from the attached mkuzip.script sequence of
commands.
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
Nostalgia ain't what it used to be.
Script started on Thu Dec 30 16:50:57 2004
Starting interactive C shell
[EMAIL PROTECTED] ~/fbsd/r/src/usr.bin/mkuzip] `make -V .OBJDIR`/`make -V
PROG` -v -s 65536 -o dns-stdin.uz /dev/stdin ~/dns.iso
data size 5505024 bytes, number of clusters 84, index lengh 680 bytes
cluster #0, in 65536 bytes, out 2263 bytes
cluster #1, in 65536 bytes, out 11581 bytes
[snip more of the same]
cluster #82, in 65536 bytes, out 11684 bytes
cluster #83, in 65536 bytes, out 752 bytes
padding data with 161 bytes so that file size is multiple of 512
compressed data to 1361920 bytes, saved 4143104 bytes, 75.26% decrease.
[EMAIL PROTECTED] ~/fbsd/r/src/usr.bin/mkuzip] sudo mdconfig -a -f dns-stdin.uz
otp-md5 455 st1434 ext
Password:
md0
[EMAIL PROTECTED] ~/fbsd/r/src/usr.bin/mkuzip] sudo mount_cd9660 /dev/md0.uzip
/mnt
[EMAIL PROTECTED] ~/fbsd/r/src/usr.bin/mkuzip] sudo find /mnt | wc -l
604
[EMAIL PROTECTED] ~/fbsd/r/src/usr.bin/mkuzip] sudo md5
/mnt/djbdns-1.05/tinydns
MD5 (/mnt/djbdns-1.05/tinydns) = d16c2fe610c19148ff005fb35242561c
[EMAIL PROTECTED] ~/fbsd/r/src/usr.bin/mkuzip] sudo md5
/home/roam/fbsd/r/ports/dns/djbdns/work/djbdns-1.05/tinydns
MD5 (/home/roam/fbsd/r/ports/dns/djbdns/work/djbdns-1.05/tinydns) =
d16c2fe610c19148ff005fb35242561c
[EMAIL PROTECTED] ~/fbsd/r/src/usr.bin/mkuzip] sudo umount /mnt
[EMAIL PROTECTED] ~/fbsd/r/src/usr.bin/mkuzip] sudo mdconfig -d -u 0
[EMAIL PROTECTED] ~/fbsd/r/src/usr.bin/mkuzip] exit
exit
Script done on Thu Dec 30 16:52:53 2004
Index: src/usr.bin/mkuzip/mkuzip.c
===
RCS file: /home/ncvs/src/usr.bin/mkuzip/mkuzip.c,v
retrieving revision 1.2
diff -u -r1.2 mkuzip.c
--- src/usr.bin/mkuzip/mkuzip.c 10 Sep 2004 23:16:05 - 1.2
+++ src/usr.bin/mkuzip/mkuzip.c 30 Dec 2004 14:47:35 -
@@ -122,10 +122,28 @@
signal(SIGXFSZ, exit);
atexit(cleanup);
- if (stat(iname, sb) != 0) {
+ fdr = open(iname, O_RDONLY);
+ if (fdr 0) {
+ err(1, %s, iname);
+ /* Not reached */
+ }
+
+ /* Try seeking to the end; if that fails, fall back to fstat() */
+ memset(sb, 0, sizeof(sb));
+ sb.st_size = lseek(fdr, 0, SEEK_END);
+ if (sb.st_size 1) {
+ if (fstat(fdr, sb) != 0) {
+ err(1, %s, iname);
+ /* Not reached */
+ }
+ } else if (lseek(fdr, 0, SEEK_SET) != 0) {
err(1, %s, iname);
/* Not reached */
}
+ if (sb.st_size 1) {
+ errx(1, Could not determine the size of %s, iname);
+ /* Not reached */
+ }
hdr.nblocks = sb.st_size / hdr.blksz;
if ((sb.st_size % hdr.blksz) != 0) {
if (verbose != 0)
@@ -135,11 +153,6 @@
}
toc = safe_malloc((hdr.nblocks + 1) * sizeof(*toc));
- fdr = open(iname, O_RDONLY);
- if (fdr 0) {
- err(1, %s, iname);
- /* Not reached */
- }
fdw = open(oname, O_WRONLY | O_TRUNC | O_CREAT,
S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
if (fdw 0) {
pgpuWy2LWMvux.pgp
Description: PGP signature
Re: Creating Compressed Loop FS from stdin
On Thu, Dec 30, 2004 at 04:55:43PM +0200, Peter Pentchev wrote: On Thu, Dec 30, 2004 at 04:20:16PM +0200, Maxim Sobolev wrote: You don't check return code of the second lseek - I bet it fails. This probably leads to creation of seemingly valid loop fs (i.e. with valid header), but filled with zeroes or some random junk. I said I'd tested it before posting it the first time. It works. It creates a valid loop fs, containing exactly the files that are in the input ISO image. Errr. Oops. Sorry everyone - the patch does not really work. I keep testing it with a *file* passed on mkuzip's stdin, all the while feeling surprised that lseek() works on the pipe... when there is no pipe at all :( I just tested it with a real pipe, and of course, it failed. Again, sorry for wasting your time; I guess it'd be best if I tucked in for the holidays now :( G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 The rest of this sentence is written in Thailand, on pgp9wWVT6euCu.pgp Description: PGP signature
Re: Fixing Posix semaphores
On Wed, Dec 22, 2004 at 12:01:51AM +, Robert Watson wrote: On Mon, 13 Dec 2004, Joe Kelsey wrote: I have a desire to fix posix semaphores in at least 5.3. The current implementation doesn't actually follow the spirit of the standard, even though it technically qualifies in a somewhat degraded sense. I refer to the fact that the current implementation treats posix semaphores as completely contained inside the kernel and essentially divorced from the filesystem. The true spirit of the standard places the semaphores directly in the file system, similar to named pipes. However the current implementation treats the supplied name as a 14-character identifier, required to begin with a slash and contain no other slashes. Pretty weak. Well, in order to fix this, we need to add file system code and come up with a new type. I currently have some time to spend on something like this and am willing to put in whatever effort it takes. Does anyone want to add their own ideas or requirements? From my perspective, the biggest win here is that it would permit different name spaces to trivially exist using multiple mountpoints of a semfs. This would make it easy to allow applications in different jails to use identical names without colliding. FWIW, my only experience with POSIX semaphores on a system other than FreeBSD is on Darwin, where a similar model is used to that on FreeBSD: a flat kernel-maintained name space is present. I seem to remember either W. Richard Stevens's APUE, or Marc Rochkind's AUP stating that: 1. the standards say that semaphore names ought to have filesystem semantics, but... 2. the standards leave it to the implementation to define whether slashes should be allowed at all except in the first position, so... 3. portable programs should only depend on a flat namespace, especially as... 4. there are widely-used OS's (ISTR Solaris, but ICBW) that only provide a flat namespace. Thus, it would seem that even if somebody would do the work to really tie the semaphore naming fully to the filesystem, still programs that want to be Really Really Portable would not dare use this feature, wonderful as it would be for those that do :( G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? pgpvyPBl6ylZv.pgp Description: PGP signature
Re: duplicate CVS modules in merged CVSROOT
On Fri, Dec 17, 2004 at 12:09:45AM +0300, Roman Kurakin wrote: Dag-Erling Sm?rgrav: Dmitry Morozovsky [EMAIL PROTECTED] writes: It seems some checks should be added to module merging code... ...or somebody should stop using the merged CVSROOT. I suggest to add prefixes like src_cut, port_cut while merging. As discussed on Another List, that's the way it is *supposed* to be, at least for the ports_* prefix. That's the way it's been for ages now - for ports which conflict with the src tree, a 'ports_' prefix is added to the CVSROOT module definition. Lots of examples in the CVSROOT-ports/modules file :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence contradicts itself - or rather - well, no, actually it doesn't! pgpMdxGcKGuYL.pgp Description: PGP signature
Re: HD Mirroring
On Wed, Nov 24, 2004 at 10:52:11AM -0300, [EMAIL PROTECTED] wrote: Hi; Don?t know if this is the proper list to ask. If not, please forgive me. Does anybody has any hints on where to go for info about HD real time mirroring in FreeBSD? I have a mysql server that I need to mirror its data on a 2nd HD, either on the same machine or on a remote one, but it has to be in real time. Has it been or can it be done at all? Actually, it has been done, and it has been working for quite some time, in several different versions even :) Take a look at the FreeBSD Handbook: http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/ Look at chapter 16, Storage, and especially 16.5, RAID. After that, look at chapter 17, The Vinum Volume Manager. Those will probably contain most of the information that you need :) There is also an excellent separate article about Vinum at http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/vinum/ Hope that helps! G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? pgpPb4IyFgkeY.pgp Description: PGP signature
Re: tcsh is not csh
On Thu, Nov 11, 2004 at 04:00:25PM -0600, Kevin Lyons wrote: Kris Kennaway wrote: Please raise tcsh compatibility bugs with the tcsh developers. Well I think that this problem is not so much with tcsh as freebsd. If tcsh wants to pull this kind of crap, fine. But I really think it is a mistake for freebsd to put a copy of tcsh in /bin and call it csh. Folks and programs that rely on old csh get funny surprises when tcsh is called csh. For what, so that there is no tcsh in /shells? I am sure I do not have to elucidate on the problems this can cause. [disclaimer: I have not been involved in any way in the import and maintenance of tcsh in FreeBSD. Any assertions made here come purely from a user's perspective, and may thus be slightly or vastly off the mark] Now wait just a minute here. There's a little fact that I think you are missing :) What FreeBSD did ~4 years ago was NOT to take tcsh as-is and just plonk it into /bin/csh. Rather, what FreeBSD did was 1. install tcsh as /bin/tcsh (you can verify that it is there, and that it is in /etc/shells, too), and then *also* install it as /bin/csh, which - and here's the little fact that you might be missing - activates tcsh's csh compatibility mode. Yes, tcsh checks how it is being executed, and tries to emulate the historical csh behavior as best it can, if it has been invoked as 'csh' and not 'tcsh'. Thus, it seems to have been the FreeBSD Project's intention to *keep* csh compatibility for csh scripts, while also providing the extended capabilities of tcsh for those users who choose to use them by *explicitly* invoking it as tcsh. And this is why people keep telling you that you should actually complain to the tcsh developers, not the FreeBSD developers, for the incompatibilities between 44bsd-csh and tcsh *in csh-compatility mode*. Over the years, later versions of tcsh have been imported into FreeBSD, with the general goal being to incorporate the improvements *and bugfixes* that made their way into those later upstream tcsh versions. Thus, if there is a bug in tcsh's csh compatibility mode, you really might do better to report it to the tcsh maintainers - on the several occassions when I've needed to report tcsh(1) and file(1) issues to Christos Zoulas, I've found him to be quite responsive and willing to accomodate reasonable requests and bugfixes :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If wishes were fishes, the antecedent of this conditional would be true. pgp4DDEhpD8ei.pgp Description: PGP signature
Re: questionable feature in FreeBSD pmake
On Thu, Oct 28, 2004 at 03:23:02AM -0700, Dan Strick wrote:
I just spent a *very* frustrating hour trying to figure out why the
FreeBSD make program was invoking all commands to make things in a
subdirectory named obj. I eventually discovered this gem in the
make man page:
[snip]
.OBJDIR A path to the directory where the targets are built.
[snip]
1. ${MAKEOBJDIRPREFIX}/`pwd`
2. ${MAKEOBJDIR}
3. obj.${MACHINE}
4. obj
5. /usr/obj/`pwd`
I believe this feature is a real botch because it is magic, unintuitive,
and so *exceedingly* easy to invoke by mistake.
Actually, this feature lies at the base of the FreeBSD base system build
infrastructure, and it is pretty much The Feature that allows us to
build from read-only and/or NFS-mounted sources shared among wide swarms
of machines :)
[snip]
This feature is not mentioned in the pmake tutorial found in
/usr/share/doc/psd/12.make. Is it a FreeBSD-ism?
A quick glance at other BSD's make(1) manual pages, all available from
URL:http://www.FreeBSD.org/cgi/man.cgi, seems to show that .OBJDIR and
MAKEOBJDIRPREFIX handling is present in all of them, and OpenBSD's
make(1) manual lists the same search order, including 'obj.${MACHINE}'
and 'obj'.
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
I am jealous of the first word in this sentence.
pgpxz16AD420E.pgp
Description: PGP signature
Re: questionable feature in FreeBSD pmake
On Thu, Oct 28, 2004 at 01:51:00PM +0300, Peter Pentchev wrote:
On Thu, Oct 28, 2004 at 03:23:02AM -0700, Dan Strick wrote:
I just spent a *very* frustrating hour trying to figure out why the
FreeBSD make program was invoking all commands to make things in a
subdirectory named obj. I eventually discovered this gem in the
make man page:
[snip]
.OBJDIR A path to the directory where the targets are built.
[snip]
1. ${MAKEOBJDIRPREFIX}/`pwd`
2. ${MAKEOBJDIR}
3. obj.${MACHINE}
4. obj
5. /usr/obj/`pwd`
I believe this feature is a real botch because it is magic, unintuitive,
and so *exceedingly* easy to invoke by mistake.
Actually, this feature lies at the base of the FreeBSD base system build
infrastructure, and it is pretty much The Feature that allows us to
build from read-only and/or NFS-mounted sources shared among wide swarms
of machines :)
Oh, and let's not forget cross-platform builds, too.
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If I had finished this sentence,
pgphcVXUhUad8.pgp
Description: PGP signature
[CFR] Specify the lock(1) timeout unit
Hi,
Here's a little patch that teaches lock(1) about timeouts specified in
seconds, hours, or days in addition to the minutes it currently assumes.
I could commit this in a week if there are no objections.
G'luck,
Peter
Index: src/usr.bin/lock/lock.1
===
RCS file: /home/ncvs/src/usr.bin/lock/lock.1,v
retrieving revision 1.11
diff -u -r1.11 lock.1
--- src/usr.bin/lock/lock.1 2 Jul 2004 22:22:27 - 1.11
+++ src/usr.bin/lock/lock.1 21 Oct 2004 10:39:13 -
@@ -42,6 +42,7 @@
.Nm
.Op Fl npv
.Op Fl t Ar timeout
+.Op Fl u Ar unit
.Sh DESCRIPTION
The
.Nm
@@ -63,7 +64,22 @@
.It Fl t Ar timeout
The time limit (default 15 minutes) is changed to
.Ar timeout
-minutes.
+minutes, or units specified by the
+.Fl u
+option.
+.It Fl u Ar unit
+Specify the time measurement unit for the time limit.
+The
+.Ar unit
+argument may be one of
+.Sq s
+for seconds,
+.Sq m
+for minutes (the default),
+.Sq h
+for hours, or
+.Sq d
+for days.
.It Fl v
Disable switching virtual terminals while this terminal is locked.
This option is implemented in a way similar to the
Index: src/usr.bin/lock/lock.c
===
RCS file: /home/ncvs/src/usr.bin/lock/lock.c,v
retrieving revision 1.18
diff -u -r1.18 lock.c
--- src/usr.bin/lock/lock.c 22 Jan 2004 04:24:15 - 1.18
+++ src/usr.bin/lock/lock.c 21 Oct 2004 11:07:36 -
@@ -85,6 +85,20 @@
long nexttime; /* keep the timeout time */
intno_timeout; /* lock terminal forever */
intvtyunlock; /* Unlock flag and code. */
+const char *timeout_str = minute;
+inttimeout_mul = 60;
+
+struct timeout_spec {
+ char spec;
+ int mul;
+ const char *str;
+} timeout_spec[] = {
+ {'s', 1, second},
+ {'m',60, minute},
+ {'h', 3600, hour},
+ {'d', 86400, day},
+ {'\0',0, NULL},
+};
/*ARGSUSED*/
int
@@ -98,20 +112,31 @@
int ch, failures, sectimeout, usemine, vtylock;
char *ap, *mypw, *ttynam, *tzn;
char hostname[MAXHOSTNAMELEN], s[BUFSIZ], s1[BUFSIZ];
+ struct timeout_spec *ts;
openlog(lock, LOG_ODELAY, LOG_AUTH);
sectimeout = TIMEOUT;
+ timeout_mul = 60;
mypw = NULL;
usemine = 0;
no_timeout = 0;
vtylock = 0;
- while ((ch = getopt(argc, argv, npt:v)) != -1)
+ while ((ch = getopt(argc, argv, npt:u:v)) != -1)
switch((char)ch) {
case 't':
if ((sectimeout = atoi(optarg)) = 0)
errx(1, illegal timeout value);
break;
+ case 'u':
+ for (ts = timeout_spec; ts-spec != '\0'; ts++)
+ if (ts-spec == optarg[0])
+ break;
+ if (ts-spec == '\0')
+ errx(1, illegal timeout unit specifier);
+ timeout_mul = ts-mul;
+ timeout_str = ts-str;
+ break;
case 'p':
usemine = 1;
if (!(pw = getpwuid(getuid(
@@ -128,7 +153,7 @@
default:
usage();
}
- timeout.tv_sec = sectimeout * 60;
+ timeout.tv_sec = sectimeout * timeout_mul;
setuid(getuid()); /* discard privs */
@@ -139,7 +164,7 @@
errx(1, not a terminal?);
if (gettimeofday(timval, (struct timezone *)NULL))
err(1, gettimeofday);
- nexttime = timval.tv_sec + (sectimeout * 60);
+ nexttime = timval.tv_sec + (sectimeout * timeout_mul);
timval_sec = timval.tv_sec;
timp = localtime(timval_sec);
ap = asctime(timp);
@@ -200,8 +225,8 @@
if (no_timeout)
(void)printf( no timeout.);
else
- (void)printf( timeout in %d minute%s., sectimeout,
- sectimeout != 1 ? s : );
+ (void)printf( timeout in %d %s%s., sectimeout,
+ timeout_str, sectimeout != 1 ? s : );
if (vtylock)
(void)printf( vty locked.);
(void)printf(\ntime now is %.20s%s%s, ap, tzn, ap + 19);
@@ -243,7 +268,7 @@
static void
usage(void)
{
- (void)fprintf(stderr, usage: lock [-npv] [-t timeout]\n);
+ (void)fprintf(stderr, usage: lock [-npv] [-t timeout] [-u unit]\n);
exit(1);
}
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If I were you, who would be reading this sentence?
pgp3X8mkPAcXL.pgp
Description: PGP signature
Re: [CFR] Specify the lock(1) timeout unit
On Thu, Oct 21, 2004 at 04:38:10PM -0400, Robert Watson wrote:
On Thu, 21 Oct 2004, Peter Pentchev wrote:
Here's a little patch that teaches lock(1) about timeouts specified in
seconds, hours, or days in addition to the minutes it currently assumes.
I could commit this in a week if there are no objections.
I think the normal convention here (see also shutdown(8), etc) is to have
the unit be specified as part of the time specification rather than as a
separate argument. I.e., lock -t 5m rather than lock -t 5 -u m. If we
don't already have it, maybe we need humanize and dehumanize functions for
time as well as disk storage?
[randomly picking this message to reply to, since the others voiced
the same concern and suggestion]
Yep, on second thought it only seems natural to append the unit to the
time specification; guess I wasn't thinking straight earlier today when
I whipped this up in a hurry... Thanks everyone for pointing out the
blindingly obvious - in this case, it *was* needed! :) Attached is an
almost trivial patch that implements this, parsing things like '10s',
'2m', '15h', or '2d' just as the previous version did - seconds,
minutes, hours, days.
As to factoring out the time specification parsing, it may not be just
as easy as with disk storage units. The main problem here is that the
utilites that parse time specifiers do so for a variety of different
reasons, and then use the result in different ways. The secondary
problem, maybe even more severe, is that the different utilities parse
very different time formats, e.g. date(1) pretty much only understands
+/-num[ymwdHMS], shutdown(8) takes either +minutes or a full or partial
[[[yy]mm]dd]hhmmss specification, and find(1) and cvs(1) use the GNU
getdate.y thing which is... well, let me say 'hairy' lest I use a
stronger word. (As a side note, wow, I never knew that find(1) could do
'last year', 'a fortnight ago', or '22:00 IDLW'; makes sense, though,
since they use the same code.)
Sooo.. if we should create a unified time parsing function, what should
it parse - an interval, an absolute time, or what? That is, what should
it *return* - an interval in seconds, or the absolute time (time_t or
struct tm) that the input specifies either directly or as an offset from
the current time, both, neither, or the air velocity of an unladen
swallow? How should it deal with nonexistent times - return an error,
try to round them up, try to round them down, or silently convert them
to the Antartica/South_Pole zone and snicker behind the curtain? How
should it deal with month specifications? (gee, I hope no one tries to
use a month unit as a lock(1) timeout, but you never know with some
people)
Anyway, here's the lock(1) patch that lets it handle 's', 'm', 'h', or
'd' appended to the timeout value.
G'luck,
Peter
Index: src/usr.bin/lock/lock.1
===
RCS file: /home/ncvs/src/usr.bin/lock/lock.1,v
retrieving revision 1.11
diff -u -r1.11 lock.1
--- src/usr.bin/lock/lock.1 2 Jul 2004 22:22:27 - 1.11
+++ src/usr.bin/lock/lock.1 21 Oct 2004 23:05:25 -
@@ -64,6 +64,21 @@
The time limit (default 15 minutes) is changed to
.Ar timeout
minutes.
+The timeout value may optionally be followed by a time unit specifier,
+one of
+.Sq s
+for seconds,
+.Sq m
+for minutes (the default),
+.Sq h
+for hours, or
+.Sq d
+for days.
+Thus,
+.Sq -t 2
+would specify a timeout of two minutes, while
+.Sq -t 10s
+would specify a timeout of ten seconds.
.It Fl v
Disable switching virtual terminals while this terminal is locked.
This option is implemented in a way similar to the
Index: src/usr.bin/lock/lock.c
===
RCS file: /home/ncvs/src/usr.bin/lock/lock.c,v
retrieving revision 1.18
diff -u -r1.18 lock.c
--- src/usr.bin/lock/lock.c 22 Jan 2004 04:24:15 - 1.18
+++ src/usr.bin/lock/lock.c 21 Oct 2004 23:06:59 -
@@ -85,6 +85,20 @@
long nexttime; /* keep the timeout time */
intno_timeout; /* lock terminal forever */
intvtyunlock; /* Unlock flag and code. */
+const char *timeout_str = minute;
+inttimeout_mul = 60;
+
+struct timeout_spec {
+ char spec;
+ int mul;
+ const char *str;
+} timeout_spec[] = {
+ {'s', 1, second},
+ {'m',60, minute},
+ {'h', 3600, hour},
+ {'d', 86400, day},
+ {'\0',0, NULL},
+};
/*ARGSUSED*/
int
@@ -96,8 +110,9 @@
struct itimerval ntimer, otimer;
struct tm *timp;
int ch, failures, sectimeout, usemine, vtylock;
- char *ap, *mypw, *ttynam, *tzn;
+ char *ap, *mypw, *ttynam, *tzn, *endarg;
char hostname[MAXHOSTNAMELEN], s[BUFSIZ], s1[BUFSIZ];
+ struct timeout_spec *ts;
openlog(lock, LOG_ODELAY, LOG_AUTH);
@@ -109,8 +124,19
Re: [PATCH] add '-' glibc extension to strftime(3)
On Sun, Oct 17, 2004 at 01:23:02AM +0800, Xin LI wrote: Hi, folks, It turns out that the GNU extension '-' in their strftime(3) implementation is somewhat popular in several applications. The patch in the last part of this e-mail will add a simulate implementation for it. Thanks for taking this up! Just a couple of comments further down... My question is: (1) Am I doing things cleanly and correctly? I have attempted to keep the code style consistent with the old one and style(9) but maybe I have missed something else, or did not do it sufficently? (2) Is the way of implementing it clean enough? Thanks for any comments! Index: strftime.3 === RCS file: /home/fcvs/src/lib/libc/stdtime/strftime.3,v retrieving revision 1.34 diff -u -r1.34 strftime.3 --- strftime.32 Jul 2004 23:52:12 - 1.34 +++ strftime.316 Oct 2004 17:13:08 - @@ -36,7 +36,7 @@ .\ @(#)strftime.3 8.1 (Berkeley) 6/4/93 .\ $FreeBSD: src/lib/libc/stdtime/strftime.3,v 1.34 2004/07/02 23:52:12 ru Exp $ .\ -.Dd January 4, 2003 +.Dd October 17, 2004 .Dt STRFTIME 3 .Os .Sh NAME @@ -216,6 +216,8 @@ is replaced by national representation of the date and time (the format is similar to that produced by .Xr date 1 ) . +.It Cm %-* +GLIBC extensions. Do not do padding when making output. In mdoc manual pages, it is customary to start new sentences on a new line, avoiding the so-called hard sentence break of two spaces :) + pt = _conv(t-tm_mday, (Palternative == PAD_LESS) ? + %d : %2d, In view of future extensions (PAD_SPACE, etc), could this not be done better with an array of printf format specifiers, indexed by Palternative? Thanks for doing the work, though! G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? pgpawonmBz22j.pgp Description: PGP signature
Re: Freebsd assembly programming - IN/OUT commands.
On Sun, Oct 17, 2004 at 04:00:57PM +0300, Giorgos Keramidas wrote: On 2004-10-16 14:03, Jan Opacki [EMAIL PROTECTED] wrote: I had a short look at your fbd assembly tutorial. I'm have a such problem useing IN, OUT commands. In my case i want to speak with cmos by port 70 and 71. We both know that fbsd as same as linux works in safe mode. So we need a permission to use each port. In linux it's a system call sys_ioperm (http://www.die.net/doc/linux/man/man2/ioperm.2.html). How to ask FreeBSD to allow us to use those ports ? And then we could simply do: mov al, 0 out 70h, al nop nop nop nop in al, 71h Do you haveny any idea ? Look at the io(4) manpage. You need superuser access to work with /dev/io and even then your program should be very careful about not messing up badly with the hardware, but I think it does what you need. Of course, a bit more controlled way (as described in the io(4) manpage, too), would be to use the i386_set_ioperm(2) syscall :) It is a bit non-portable, true, but since Jan uses MASM-style assembly and mentions ports 70h and 71h, I think it would do what he needs. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This inert sentence is my body, but my soul is alive, dancing in the sparks of your brain. pgpHuMEmliiOf.pgp Description: PGP signature
Re: [PATCH] add '-' glibc extension to strftime(3)
On Sun, Oct 17, 2004 at 05:43:53PM +0300, Peter Pentchev wrote: On Sun, Oct 17, 2004 at 01:23:02AM +0800, Xin LI wrote: Hi, folks, It turns out that the GNU extension '-' in their strftime(3) implementation is somewhat popular in several applications. The patch in the last part of this e-mail will add a simulate implementation for it. Thanks for taking this up! Just a couple of comments further down... [snip] + pt = _conv(t-tm_mday, (Palternative == PAD_LESS) ? + %d : %2d, In view of future extensions (PAD_SPACE, etc), could this not be done better with an array of printf format specifiers, indexed by Palternative? Just in case this was a bit unclear, I mean something like pt = _conv(t-tm_mday, fmt_mday[Palternative], ...); G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the meaning of this sentence. pgphQFbnmveYB.pgp Description: PGP signature
Re: Kernel-loadable Root Kits
On Sat, Sep 08, 2001 at 05:43:41AM -0400, Deepak Jain wrote: Short question: Is there a way to prevent the kernel from allowing loadable modules? Run your system in securelevel 1 or higher. See the init(8) manual page and the kern_securelevel_enable and kern_securelevel variables in the rc.conf(5) manual page. G'luck, Peter -- .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-security in the body of the message ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[CFR] Fix adduser's recognition of nologin
Hi,
Any objections to the following patch? The rationale is described
in PR bin/71786 - http://www.FreeBSD.org/cgi/query-pr.cgi?pr=71786
Basically, the 'exit' inside the 'cat | while' loop does not really
exit the fullpath_from_shell() function, so if the admin specifies
'nologin' as the new user's shell, fullpath_from_shell() actually
outputs /sbin/nologin\n/sbin/nologin or something similar, and this
corrupts the modified master.passwd file.
In the PR, the originator confirmed that this solved the problem.
I could commit it if no one has any objections.
Index: src/usr.sbin/adduser/adduser.sh
===
RCS file: /home/ncvs/src/usr.sbin/adduser/adduser.sh,v
retrieving revision 1.24
diff -u -r1.24 adduser.sh
--- src/usr.sbin/adduser/adduser.sh 28 Aug 2004 14:32:10 - 1.24
+++ src/usr.sbin/adduser/adduser.sh 16 Sep 2004 11:43:23 -
@@ -126,6 +126,13 @@
_shell=$1
[ -z $_shell ] return 1
+ # /usr/sbin/nologin is a special case
+ if [ $_shell = ${NOLOGIN} -o \
+ $_shell = ${NOLOGIN_PATH} ]; then
+ echo ${NOLOGIN_PATH}
+ return 0;
+ fi
+
cat ${ETCSHELLS} |
while read _path _junk ; do
case $_path in
@@ -141,13 +148,6 @@
esac
done
- # /usr/sbin/nologin is a special case
- if [ $_shell = ${NOLOGIN} -o \
- $_shell = ${NOLOGIN_PATH} ]; then
- echo ${NOLOGIN_PATH}
- return 0;
- fi
-
return 1
}
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
Thit sentence is not self-referential because thit is not a word.
pgp0HzxmNlFMO.pgp
Description: PGP signature
Re: Booting encrypted
On Wed, Sep 15, 2004 at 07:30:19PM -0500, Frank Knobbe wrote: On Tue, 2004-09-07 at 15:22, Steve Watt wrote: Having the password compiled in to something that's necessarily clear-text on the same media? Sorry for being late... I'm still catching up on piles of email :) Instead of having a plaintext password on the same media, how about a mechanism that reads the CPU's serial number, or some other hardware dependent number that can not be read by users on a system. If the drive gets removed from the system, the attacker would have a challenge. Of course you have to be careful before you replace failed hardware that is used to derive the key :) Don't replace the failed CPU before you decrypted... no wait... uhm... :) Okay, how about an offline copy of the number in case of hardware failure... :) Seriously though, tying the boot process to a hardware dependent value that is not accessible from within the booted system might be something to consider. Any thoughts? One word that Bruce M. Simpson already mentioned: TCPA :) Well, it's not exactly what you describe, but it is basically what you describe done right - no offense intended, of course, I mean that the TCPA specs at http://trustedcomputinggroup.org/home seem to provide the benefits that you are looking for in a framework that mostly alleviates the problems. Of course, the key word is 'mostly', and there is more to TCPA than just encrypted booting, and there are lots of people who disagree with the 'more' part, but still you might want to take a look at it. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the meaning of this sentence. pgpnGpS6hD6NJ.pgp Description: PGP signature
Re: What does it mean
On Tue, Sep 14, 2004 at 11:55:18AM +0600, Dmitry A. Bondareff wrote: Hello hackers! On my system which connected to Internet I''ll see many processes like (sh): # ps axu | more USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 59548 1,0 0,0 00 ?? Z11:00 0:00,00 (sh) root 59588 0,0 0,0 00 ?? Z11:02 0:00,00 (sh) root185 0,0 0,0 00 ?? Z 204 0:00,00 (sh) WHAT IS IT ?? According to the ps(1) manual page, the 'Z' flag means that the process is what is commonly known as 'zombie' - a process that has ended its execution, either exiting voluntarily or killed by a signal, and is being kept in memory until its parent process collects whatever information is necessary. The fact that you are seeing those zombie processes may mean one of two things: either the 'sh' processes have ended really, really recently and their parent has not yet had a chance to invoke one of the functions described in the wait(2) manual page to collect the information, or the 'sh' processes have terminated some time ago but their parent is busy doing something else, possibly locked up or something. You may gather a lot more information by including the parent process ID in the 'ps' output: try 'ps axl' or 'ps axlwww', see what has invoked all those 'sh' processes, see if it has left any logs as to why, what happened, and so on. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I've heard that this sentence is a rumor. pgprYo7VhLM6q.pgp Description: PGP signature
Re: struct proc - basic question
On Mon, Sep 13, 2004 at 10:30:31PM +1000, Sam Lawrance wrote: On Mon, 2004-09-13 at 22:01, Joanna Sledzik wrote: Hi :) I'm very very begginer in Unix system programming. What function should I use to catch the struct proc for some process? Is it possible to get the pointer to struct proc using for example the pid_t pid as an argument? From userland, maybe the kvm_* functions will do what you want. See the kvm, kvm_open and kvm_getprocs manpages. The kern.proc.all sysctl might be a better idea; see my other e-mail for details. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am jealous of the first word in this sentence. pgpEMWISuGdfZ.pgp Description: PGP signature
Re: struct proc - basic question
On Mon, Sep 13, 2004 at 02:01:39PM +0200, Joanna Sledzik wrote: Hi :) I'm very very begginer in Unix system programming. What function should I use to catch the struct proc for some process? Is it possible to get the pointer to struct proc using for example the pid_t pid as an argument? Yes, the function you are looking for is #include sys/proc.h struct proc *pfind(pid_t pid) You pass it a pid_t argument and it returns a pointer to a proc structure. However, note that the pfind() function is only available to code running in kernel space - it has to be invoked either from a kernel module, or from code compiled into the kernel itself. If you want to get a process's struct proc from a user-space program, there are two ways to go about it: - use libkvm to muck around the kernel's memory: this is a pretty bad approach for most cases, especially as the kernel's internal structures may change even as you try to examine them and follow the list pointers. If you choose this approach, take a look at the kvm(3) manual page, and note that you need to look for the 'allproc' list, which is usually a singly-linked list, but see sys/proc.h for details. - use the sysctl(3) interface to fetch the value of the kern.proc.all sysctl. It is a snapshot of the current process info, see the kinfo_proc structure and the comments around it in the sys/user.h file for more information. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. pgpORcTg5upe2.pgp Description: PGP signature
Re: [PATCH] Fix USB panics
On Wed, Sep 08, 2004 at 11:37:07AM -0600, M. Warner Losh wrote: Peter, thanks again for the excellent anaylsis of the problem. I introduced this when I cleaned up the load a driver will now cause usb to attach a device case. You are correct as far as I can tell and can test. Here's the patch that I've come up with. Does it work for you? Yes, this patch works just fine. I assume you will commit it without the printf and indentation chunks, though? :) Thanks again! G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 because I didn't think of a good beginning of it. pgpVspZeFNrWW.pgp Description: PGP signature
[PATCH] Fix USB panics
Hi,
A couple of days ago I started experimenting with a new USB device,
which has no FreeBSD driver, and within the first minute of playing with
it, my kernel panicked - something that I hadn't seen for about a month,
even with 5.x :)
So here's a How to Panic a RELENG_5 Kernel In Five Easy Steps :)
1. Make sure usbd is not running so it cannot load drivers on demand.
2. kldload usb, and do not load *any* USB device drivers, not even ugen.
3. Plug a device, any device.
3a. usbd_probe_and_attach() looks for a specific driver, and fails.
3b. usbd_probe_and_attach() looks for a generic driver, and fails.
3c. usbd_probe_and_attach() leaves the newly-allocated device_t
structure in place (and added to the parent bus), but removes any
subdevs traces in the usbd_device_handle.
4. Unplug the device.
4a. usb_disconnect_port() does not find the device_t structure, since it
has been removed from usbd_device_handle's subdevs.
4b. usb_disconnect_port() frees the usbd_device_handle.
5. kldload ugen
5a. busdma walks the buses, looking for devices that this driver should
attach to.
5b. busdma calls ugen_attach() on the somewhat orphaned device_t.
5c. ugen_attach() calls usbd_devinfo() on the usbd_device_handle pointer
extracted from the device_t's softc - which was kinda freed in step
4b above :)
5d. Congratulations, you have reached kdb's panic handler! :)
So.. what should be done about it? Basically, the problem is that
usbd_probe_and_attach() leaves an orphaned device_t pointing to the
usbd_device_handle that will be freed when the hardware device is
physically unplugged.
The attached patch seems to solve the problem - and a couple of related
others - at least for me. The #ifdef's are effectively #if 0's, I've
just left them in to keep a perspective on the original code. The idea
is to keep the device_t pointer in the usbd_device_handle, but take care
to check if the device is actually attached before dereferencing it.
Also, uhub had to be taught not to remove the device_t pointer on driver
unload, since the hardware is still physically attached to the machine
and the device_t is still attached to the bus, even though there is no
driver for it. This makes uhub's child_detached handler mostly a no-op,
with the exception of the panic if the uhub itself is not initialized
yet; should the whole handler be removed, since the only thing it does
ought to be handled by usb_disconnect_port() already?
Is this even the right direction? IMHO, this situation ought to be
resolved one way or another before 5.3 hits the shelves, even if the
solution has nothing to do with my proposed patch :)
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be
false.
Index: dev/usb/uhub.c
===
RCS file: /home/ncvs/src/sys/dev/usb/uhub.c,v
retrieving revision 1.62
diff -u -r1.62 uhub.c
--- dev/usb/uhub.c 15 Aug 2004 23:39:18 - 1.62
+++ dev/usb/uhub.c 8 Sep 2004 14:06:45 -
@@ -707,7 +707,9 @@
continue;
for (i = 0; dev-subdevs[i]; i++) {
if (dev-subdevs[i] == child) {
+#ifdef ROAM_SKIP_USB_DEVICE_LEAK
dev-subdevs[i] = NULL;
+#endif
return;
}
}
Index: dev/usb/usb_subr.c
===
RCS file: /home/ncvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.69
diff -u -r1.69 usb_subr.c
--- dev/usb/usb_subr.c 15 Aug 2004 23:39:18 - 1.69
+++ dev/usb/usb_subr.c 8 Sep 2004 14:05:51 -
@@ -1016,9 +1016,11 @@
if (dv != NULL) {
return (USBD_NORMAL_COMPLETION);
}
+#ifdef ROAM_SKIP_USB_DEVICE_LEAK
tmpdv = dev-subdevs;
dev-subdevs = 0;
free(tmpdv, M_USB);
+#endif
/*
* The generic attach failed, but leave the device as it is.
@@ -1346,7 +1348,7 @@
di-udi_speed = dev-speed;
if (dev-subdevs != NULL) {
- for (i = 0; dev-subdevs[i]
+ for (i = 0; dev-subdevs[i] device_is_attached(dev-subdevs[i])
i USB_MAX_DEVNAMES; i++) {
strncpy(di-udi_devnames[i], USBDEVPTRNAME(dev-subdevs[i]),
USB_MAX_DEVNAMELEN);
pgp5RaXRKVT8c.pgp
Description: PGP signature
Re: [PATCH] Fix USB panics
On Wed, Sep 08, 2004 at 11:17:06AM -0600, M. Warner Losh wrote:
[[ redirected to hackers only ]]
Thanks for looking over this so quickly!
In message: [EMAIL PROTECTED]
Peter Pentchev [EMAIL PROTECTED] writes:
[snip]
: So here's a How to Panic a RELENG_5 Kernel In Five Easy Steps :)
:
: 1. Make sure usbd is not running so it cannot load drivers on demand.
:
: 2. kldload usb, and do not load *any* USB device drivers, not even ugen.
:
: 3. Plug a device, any device.
: 3a. usbd_probe_and_attach() looks for a specific driver, and fails.
: 3b. usbd_probe_and_attach() looks for a generic driver, and fails.
: 3c. usbd_probe_and_attach() leaves the newly-allocated device_t
: structure in place (and added to the parent bus), but removes any
: subdevs traces in the usbd_device_handle.
Leaving it in place is the right thing to do. It looks like the
second half of this isn't.
Ahh... hold on to this thought, now.
: So.. what should be done about it? Basically, the problem is that
: usbd_probe_and_attach() leaves an orphaned device_t pointing to the
: usbd_device_handle that will be freed when the hardware device is
: physically unplugged.
I'd use different terms to describe it, but what you are saying is
essentially correct.
Yeah, well, this is the first time I dip my fingers into both the USB
code and the busdma framework at all, so I'm probably saying a lot of
things the wrong way :)
: The attached patch seems to solve the problem - and a couple of related
: others - at least for me. The #ifdef's are effectively #if 0's, I've
: just left them in to keep a perspective on the original code. The idea
: is to keep the device_t pointer in the usbd_device_handle, but take care
: to check if the device is actually attached before dereferencing it.
H
That's the third chunk of the patch, where I added the
device_is_attached() check to usbd_fill_deviceinfo(). Until now, the
device could never possibly have been NOT attached, since
usbd_probe_and_attach() would never have left a non-NULL subdev in
place. How's that for a double.. no, quadruple negative in the last
sentence, now?
[snip]
: Is this even the right direction? IMHO, this situation ought to be
: resolved one way or another before 5.3 hits the shelves, even if the
: solution has nothing to do with my proposed patch :)
Yes. I don't like parts of it, but they are the parts that you
yourself don't like either :-(.
: Index: dev/usb/uhub.c
: ===
: RCS file: /home/ncvs/src/sys/dev/usb/uhub.c,v
: retrieving revision 1.62
: diff -u -r1.62 uhub.c
: --- dev/usb/uhub.c 15 Aug 2004 23:39:18 - 1.62
: +++ dev/usb/uhub.c 8 Sep 2004 14:06:45 -
: @@ -707,7 +707,9 @@
: continue;
: for (i = 0; dev-subdevs[i]; i++) {
: if (dev-subdevs[i] == child) {
: +#ifdef ROAM_SKIP_USB_DEVICE_LEAK
: dev-subdevs[i] = NULL;
: +#endif
: return;
: }
: }
I agree with your assessment that the above really makes the routine:
Static void
uhub_child_detached(device_t self, device_t child)
{
struct uhub_softc *sc = device_get_softc(self);
usbd_device_handle devhub = sc-sc_hub;
if (!devhub-hub)
/* should never happen; children are only created after init */
panic(hub not fully initialised, but child deleted?);
}
which looks right to me (although having the panic there seems overly
defensive).
Yep, that's why I wondered if the whole function should not be removed.
Still, it might be a good thing to leave it in, just in case - after
all, this is not an overly-often executed path.
: Index: dev/usb/usb_subr.c
: ===
: RCS file: /home/ncvs/src/sys/dev/usb/usb_subr.c,v
: retrieving revision 1.69
: diff -u -r1.69 usb_subr.c
: --- dev/usb/usb_subr.c 15 Aug 2004 23:39:18 - 1.69
: +++ dev/usb/usb_subr.c 8 Sep 2004 14:05:51 -
: @@ -1016,9 +1016,11 @@
: if (dv != NULL) {
: return (USBD_NORMAL_COMPLETION);
: }
: +#ifdef ROAM_SKIP_USB_DEVICE_LEAK
: tmpdv = dev-subdevs;
: dev-subdevs = 0;
: free(tmpdv, M_USB);
: +#endif
:
: /*
: * The generic attach failed, but leave the device as it is.
I'm not sure I understand why the above fixes anything. Is it because
it makes the proper references go away? If so, it can likely be
deleted. I'll need to thread through the code to see if any of the
other instances of those 3 lines of code can go.
Remember the thought I told you to hold on to? :) This is the part
where usbd_probe_and_attach() removes the usbd_device_handle's reference
to the device_t - and now usb_disconnect_port() thinks it's safe to
remove the usbd_device_handle. However
Re: [PATCH] Fix USB panics
On Wed, Sep 08, 2004 at 11:37:07AM -0600, M. Warner Losh wrote: Peter, thanks again for the excellent anaylsis of the problem. I introduced this when I cleaned up the load a driver will now cause usb to attach a device case. You are correct as far as I can tell and can test. Here's the patch that I've come up with. Does it work for you? Unfortunately, I have to run right now, but from a quick look over it seems that it will work. I'll test it and let you know tomorrow at the latest. Thanks! G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 No language can express every thought unambiguously, least of all this one. pgpTRczu3ocsz.pgp Description: PGP signature
[CFR] OpenSSL ENGINE fix
Hi,
The stunnel port had been badly broken on -CURRENT for some time, and
today I seem to have tracked it down. There is a problem in
OpenSSL's ENGINE code, which seems to depend on realloc()'s initializing
unused memory with zeroes. Since this is certainly not true with
malloc's 'J' option, the ENGINE code never actually runs out of RAND
routines to look for, and dumps core on attempting to dereference a
structure at 0xd0d0d0d0.
The following simple patch seems to fix this particular problem, but I
think there are others lurking close beneath the surface. When I built
stunnel with this patch, it did not immediately segfault on
initialization, but it did later, when it attempted to get a couple of
random bytes in order to actually establish an SSL connection. A quick
examination shows that the ENGINE code had successfully loaded and
initialized all built-in engines and then tried to use the last one
loaded - in this case, the 4758cca one - which promptly invoked a
function pointed to by the static randomNumberGenerate variable, which,
as you may have guessed by this point, held a NULL value. Apparently,
something else is rotten in ENGINE initialization land, and (at least)
the 4758cca driver cannot properly detect that it has not properly
detected its hardware :(
Still, I think the attached patch should be committed and MT5'd before
5.3-RELEASE, to fix at least one of the flaws. Also here is a simple C
program that illustrates the problem - just compile it and run it on a
stock 5.x or 6.x system, and I'd be, well, somewhat surprised if it gets
to the printf's at all.
So.. the patch itself:
Index: src/crypto/openssl/crypto/engine/eng_table.c
===
RCS file: /home/ncvs/src/crypto/openssl/crypto/engine/eng_table.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 eng_table.c
--- src/crypto/openssl/crypto/engine/eng_table.c28 Jan 2003 21:22:30 -
1.1.1.1
+++ src/crypto/openssl/crypto/engine/eng_table.c2 Sep 2004 14:40:52 -
@@ -287,7 +287,7 @@
}
trynext:
ret = sk_ENGINE_value(fnd-sk, loop++);
- if(!ret)
+ if(!ret || loop == sk_ENGINE_num(fnd-sk))
{
#ifdef ENGINE_TABLE_DEBUG
fprintf(stderr, engine_table_dbg: %s:%d, nid=%d, no
And the test program:
#include openssl/lhash.h
#include openssl/ssl.h
#include openssl/err.h
#include openssl/crypto.h /* for CRYPTO_* and SSLeay_version */
#include openssl/rand.h
#if SSLEAY_VERSION_NUMBER = 0x00907000L
#include openssl/engine.h
#else
#error weird openssl version
#endif
int main(void)
{
ENGINE_load_builtin_engines();
ENGINE_register_all_complete();
if (RAND_status()) {
printf(RAND_status said ok\n);
} else {
printf(RAND_status kinda sorta failed\n);
}
return (0);
}
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If there were no counterfactuals, this sentence would not have been paradoxical.
pgpRwpYouoP8f.pgp
Description: PGP signature
Re: [CFR] OpenSSL ENGINE fix
On Thu, Sep 02, 2004 at 07:03:00PM +0300, Peter Pentchev wrote:
Hi,
The stunnel port had been badly broken on -CURRENT for some time, and
today I seem to have tracked it down. There is a problem in
OpenSSL's ENGINE code, which seems to depend on realloc()'s initializing
unused memory with zeroes. Since this is certainly not true with
malloc's 'J' option, the ENGINE code never actually runs out of RAND
routines to look for, and dumps core on attempting to dereference a
structure at 0xd0d0d0d0.
The following simple patch seems to fix this particular problem, but I
think there are others lurking close beneath the surface. When I built
stunnel with this patch, it did not immediately segfault on
initialization, but it did later, when it attempted to get a couple of
random bytes in order to actually establish an SSL connection. A quick
examination shows that the ENGINE code had successfully loaded and
initialized all built-in engines and then tried to use the last one
loaded - in this case, the 4758cca one - which promptly invoked a
function pointed to by the static randomNumberGenerate variable, which,
as you may have guessed by this point, held a NULL value. Apparently,
something else is rotten in ENGINE initialization land, and (at least)
the 4758cca driver cannot properly detect that it has not properly
detected its hardware :(
Oh, and of course, here's a program that demonstrates the null pointer
problem after the eng_table.c patch is applied:
#include openssl/lhash.h
#include openssl/ssl.h
#include openssl/err.h
#include openssl/crypto.h /* for CRYPTO_* and SSLeay_version */
#include openssl/rand.h
#if SSLEAY_VERSION_NUMBER = 0x00907000L
#include openssl/engine.h
#else
#error weird openssl version
#endif
int main(void)
{
unsigned char buf[256];
int ret;
ENGINE_load_builtin_engines();
ENGINE_register_all_complete();
if (RAND_status()) {
printf(RAND_status said ok\n);
} else {
printf(RAND_status kinda sorta failed\n);
}
ret = RAND_pseudo_bytes(buf, sizeof(buf) / 2);
printf(RAND_pseudo_bytes() returned %d\n, ret);
return (0);
}
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If I had finished this sentence,
pgpW2tc4dntHa.pgp
Description: PGP signature
Re: freebsd-gnats-submit@FreeBSD.org
On Thu, Jul 29, 2004 at 12:25:02AM +0900, Eitarou Kamo wrote: Hi guys, I have a problem with my mail env. My problem is that suddenly some mails for [EMAIL PROTECTED] came to my mail client. What happened? I don't subscribe such a list. GNATS is FreeBSD's problem report (PR) system. freebsd-gnats-submit is the address that PR's and followups to PR's should be sent to. Either you have filed a PR, or somebody has sent a follow-up message to one of your PR's. Alternatively, it could just be some spammer forging e-mail addresses and choosing them at random. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence would be seven words long if it were six words shorter. pgp7ceJ39Ea2s.pgp Description: PGP signature
Re: RFC: -exit option for find(1)
On Fri, Jul 16, 2004 at 11:58:07AM +0400, Denis Antrushin wrote: Alfred Perlstein wrote: I'm up too late, this doesn't work because find returns success whenever it successfully runs thought everything. Perhaps the primary change to just -exit which would make find exit successfully, and if the primary is never encountered (ie. our find logic never hits it) find would exit with a non-zero exit status? Ideas? Better ideas? The reason I want this is to avoid extracting a tarball over a directory that has files in it that are newer than the tarball. Neither tar nor find seem to make this easy... What about this: test -n `find . -type f -newer ../src.tar.gz` echo hi I believe Alfred's problem with this is that it will still traverse the whole hierarchy even after a match is found. In some cases, the hierarchy may be huge, and if the match is within the first 100-200 files, well... :) I wonder if it wouldn't be a bit better to add to find(1) something like -maxmatches N, similar to Alfred's idea, but not limited to a single match? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 No language can express every thought unambiguously, least of all this one. pgppRQamZIJBv.pgp Description: PGP signature
Re: RFC: -exit option for find(1)
On Fri, Jul 16, 2004 at 05:28:57PM +0300, Peter Pentchev wrote: On Fri, Jul 16, 2004 at 11:58:07AM +0400, Denis Antrushin wrote: Alfred Perlstein wrote: I'm up too late, this doesn't work because find returns success whenever it successfully runs thought everything. Perhaps the primary change to just -exit which would make find exit successfully, and if the primary is never encountered (ie. our find logic never hits it) find would exit with a non-zero exit status? Ideas? Better ideas? The reason I want this is to avoid extracting a tarball over a directory that has files in it that are newer than the tarball. Neither tar nor find seem to make this easy... What about this: test -n `find . -type f -newer ../src.tar.gz` echo hi I believe Alfred's problem with this is that it will still traverse the whole hierarchy even after a match is found. In some cases, the hierarchy may be huge, and if the match is within the first 100-200 files, well... :) I wonder if it wouldn't be a bit better to add to find(1) something like -maxmatches N, similar to Alfred's idea, but not limited to a single match? Well, I've just gone ahead and implemented it: say hello to the new -maxmatch N and -minmatch N primaries: -maxmatch n Always true; exits after printing out n matching filenames. If any -maxmatch primary is specified, it applies to the entire expression even if it would not normally be evaluated. -maxmatch 0 makes find exit immediately without performing any filesystem traversal. -minmatch n Always true; exits with a non-zero exit code if less than n matching filenames were printed out at the end of the search. If any -minmatch primary is specified, it applies to the entire expression even if it would not normally be evaluated. Thus, -maxmatch 1 would help in Alfred's case. Patch attached. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I had to translate this sentence into English because I could not read the original Sanskrit. Index: src/usr.bin/find/extern.h === RCS file: /home/ncvs/src/usr.bin/find/extern.h,v retrieving revision 1.21 diff -u -r1.21 extern.h --- src/usr.bin/find/extern.h 28 May 2004 17:17:15 - 1.21 +++ src/usr.bin/find/extern.h 16 Jul 2004 15:09:49 - @@ -68,6 +68,7 @@ creat_fc_links; creat_fc_ls; creat_fc_mXXdepth; +creat_fc_mXXmatch; creat_fc_name; creat_fc_newer; creat_fc_nogroup; @@ -116,6 +117,7 @@ extern int ftsoptions, isdeprecated, isdepth, isoutput, issort, isxargs; extern int mindepth, maxdepth; +extern int minmatch, maxmatch, match; extern int regexp_flags; extern time_t now; extern int dotfd; Index: src/usr.bin/find/find.1 === RCS file: /home/ncvs/src/usr.bin/find/find.1,v retrieving revision 1.66 diff -u -r1.66 find.1 --- src/usr.bin/find/find.1 7 Jul 2004 19:57:15 - 1.66 +++ src/usr.bin/find/find.1 16 Jul 2004 15:19:36 - @@ -442,6 +442,18 @@ not normally be evaluated. .Ic -maxdepth Li 0 limits the whole search to the command line arguments. +.It Ic -maxmatch Ar n +Always true; exits after printing out +.Ar n +matching filenames. +If any +.Ic -maxmatch +primary is specified, it applies to the entire expression even if it would +not normally be evaluated. +.Ic Ic -maxmatch Li 0 +makes +.Nm +exit immediately without performing any filesystem traversal. .It Ic -mindepth Ar n Always true; do not apply any tests or actions at levels less than .Ar n . @@ -451,6 +463,14 @@ not normally be evaluated. .Ic -mindepth Li 1 processes all but the command line arguments. +.It Ic -minmatch Ar n +Always true; exits with a non-zero exit code if less than +.Ar n +matching filenames were printed out at the end of the search. +If any +.Ic -minmatch +primary is specified, it applies to the entire expression even if it would +not normally be evaluated. .It Ic -mmin Ar n True if the difference between the file last modification time and the time .Nm Index: src/usr.bin/find/find.c === RCS file: /home/ncvs/src/usr.bin/find/find.c,v retrieving revision 1.17 diff -u -r1.17 find.c --- src/usr.bin/find/find.c 28 May 2004 17:17:15 - 1.17 +++ src/usr.bin/find/find.c 16 Jul 2004 15:16:10 - @@ -181,6 +181,10 @@ PLAN *p; int rval; + if (maxmatch == 0) + return (0); + + match = 0; tree = fts_open(paths, ftsoptions, (issort ? find_compare : NULL)); if (tree == NULL) err(1, ftsopen); @@ -237,5 +241,11 @@ (p-execute
Re: freebsd asm
On Wed, Jun 16, 2004 at 09:01:02AM -0700, Wes Peters wrote: On Monday 14 June 2004 07:04, Peter Pentchev wrote: On Mon, Jun 14, 2004 at 01:59:11PM +0200, Jos? Nicol?s Castellano wrote: Hello to all, I'm proud to join this mailing, having posibilities to learn some new features of freebsd system. I have to mention i did some tests in asm from freebsd-devel and i get surprised, look at this: [demon]~$ uname -a FreeBSD demon.noconname.org 5.2.1-RELEASE-p4 FreeBSD 5.2.1-RELEASE-p4 #0: Tue Apr 6 19:35:49 CEST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NocONName i386 [demon]~$ cat hello.asm %include 'system.inc' section .data holadb 'Hola', 0Ah hbytes equ $-hola section .text global _start _start: pushdword hbytes pushdword hola pushdword stdout sys.write pushdword 0 sys.exit [demon]~$ nasm -f elf hello.asm hello.asm:1: fatal: unable to open include file `system.inc' ?Where is that file?... the -current port of nasm is incomplete ? I assume you are referring to the system.inc file mentioned in http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x86- portable-code.html If so, note that this page says that you need to create this file yourself, it is neither part of nasm nor part of the standard FreeBSD distribution :) See the last paragraph on the page - Go ahead, enter it into your editor and save it as system.inc. :) Gee, maybe somebody should do that and submit the file to krion@ for inclusion in the port patches. ;^) Well, there would have to be several versions, or it would have to be automatically generated from syscalls.master... though that would require parsing C syntax. Nah, several versions should be fine, updated each time a syscall is added/removed/changed - that should not be too often, would it now? :) I'll see if I can whip up something like that. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the thought you are now thinking. pgp0rHL3G5VQJ.pgp Description: PGP signature
Re: FreeBSD or other BSD for no-MMU ARM processor ?
On Mon, Jun 14, 2004 at 03:32:09PM -0400, Gary Corcoran wrote: Does anyone know if there is a port of FreeBSD, or any of the other BSDs (e.g. NetBSD) for that matter, which will run on an ARM processor which does NOT have an MMU (Memory Management Unit)? Your best bet would be http://www.netbsd.org/Ports/ Unfortunately, I'm not too familiar with the ARM line of processors, so it's not really obvious to me if NetBSD supports architecturs without MMU's. ISTR that there was a decision very early down the line for FreeBSD to *not* support anything that didn't have an MMU.. or was that even earlier, and does it also hold true for other BSD's? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. pgp8EFKxVA5PK.pgp Description: PGP signature
Re: freebsd asm
On Mon, Jun 14, 2004 at 01:59:11PM +0200, Jos? Nicol?s Castellano wrote: Hello to all, I'm proud to join this mailing, having posibilities to learn some new features of freebsd system. I have to mention i did some tests in asm from freebsd-devel and i get surprised, look at this: [demon]~$ uname -a FreeBSD demon.noconname.org 5.2.1-RELEASE-p4 FreeBSD 5.2.1-RELEASE-p4 #0: Tue Apr 6 19:35:49 CEST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NocONName i386 [demon]~$ cat hello.asm %include 'system.inc' section .data holadb 'Hola', 0Ah hbytes equ $-hola section .text global _start _start: pushdword hbytes pushdword hola pushdword stdout sys.write pushdword 0 sys.exit [demon]~$ nasm -f elf hello.asm hello.asm:1: fatal: unable to open include file `system.inc' ?Where is that file?... the -current port of nasm is incomplete ? I assume you are referring to the system.inc file mentioned in http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x86-portable-code.html If so, note that this page says that you need to create this file yourself, it is neither part of nasm nor part of the standard FreeBSD distribution :) See the last paragraph on the page - Go ahead, enter it into your editor and save it as system.inc. :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 yields falsehood, when appended to its quotation. yields falsehood, when appended to its quotation. pgpCPU36CpqdH.pgp Description: PGP signature
Re: pkg_create @cwd and @srcdir
On Wed, May 26, 2004 at 08:19:40PM -0700, Tim Kientzle wrote: Brenden Grace wrote: In this thread: http://lists.freebsd.org/pipermail/freebsd-hackers/2003-June/001673.html some people seem to think that @cwd is broken. The man pages do not explicitly state how @cwd should operate, but currently the directory must exist for pkg_create to run properly. This is extremely annoying because build machines *must* create the final directory structure of the target install before the package can be created. I thought the directory structure is supposed to be created using mtree files? The ports collection runs 'mtree' before running the actual 'make install' in the port's working directory; as for pkg_add and generated packages, they should include a @mtree directive in +CONTENTS and an +MTREE_DIRS file... So my question is, does the 5.2.1 version of pkg_create contain a bug or is pkg_create really just very limited? Try it with bsdtar as the system default tar and see if that behaves any differently. (WITH_BSDTAR=1 in /etc/make.conf). Errr, that's all fine and good, but how about people who still use GNU tar for various reasons, such as sticking with RELENG_4? :) Or do you have any plans for MFC'ing libarchive/bsdtar into RELENG_4 (please please please!), even without making it the default? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI pgpsww0KKU857.pgp Description: PGP signature
Re: IP frag need
On Wed, May 19, 2004 at 12:22:41PM +0600, Dmitry A. Bondareff wrote: Hello hackers! I have two office in the Internet. And now I trying to make VPN between it. I using mpd for it. Client --- (mtu=1500) FreeBSD (mtu=1024) == VPN over Internet == (mtu=1024)FreeBSD (mtu=1500)--- WindowsNT Client trying to use mounted disk from WindowsNT 11.8.24.25 - WindowsNT 11.8.11.1 - FreeBSD tcpdump info: 17:26:55.100097 11.8.24.25.139 11.8.11.1.1049: tcp 1460 (DF) 17:26:55.100175 11.8.11.1 11.8.24.25: icmp: 11.8.11.1 unreachable - need to frag (mtu 1024) (DF) 17:26:57.287737 11.8.24.25.139 11.8.11.1.1049: tcp 1460 (DF) 17:26:57.287813 11.8.11.1 11.8.24.25: icmp: 11.8.11.1 unreachable - need to frag (mtu 1024) (DF) As you can see IP frag needed, but WindowsNT don't want to do it. What I cat do on FreeBSD box to solve the problem ?? If you are using a recent version of mpd, try putting the following line: set iface enable tcpmssfix in your bundle definition in mpd.conf. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 No language can express every thought unambiguously, least of all this one. pgpuxcUFWAXcZ.pgp Description: PGP signature
Re: obtaining a kernel crash dump
On Wed, May 19, 2004 at 04:34:42PM +0300, Nick Strebkov wrote: Hi there. I can't obtain a crash dump. % cat /sys/i386/conf/DEVEL | grep makeoptions makeoptions DEBUG=-g % cat /etc/rc.conf| grep dump dumpdev=/dev/ar0s1b dumpdir=/var/crash I'm testing my kernel patch and the following is what I see in /var/log/messages: Can you force the kernel to dump by using DDB? Place 'options DDB' in your kernel config, then, when the system is quiescent, hit Ctrl-Alt-Esc and type 'panic' at the DDB prompt. If this works, and you get a crash dump, then the problem might be that with your kernel patch, the kernel is panicking in a low-level layer, like memory management or disk drivers or something like that, and it simply cannot make a crash dump, since that would mean invoking code that depends on bad data or something. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? pgpx3Sb7VsHMD.pgp Description: PGP signature
Re: Loosing STDOUT after file rotation
On Fri, Apr 02, 2004 at 05:19:42PM +0200, Dag-Erling Sm?rgrav wrote: James Housley [EMAIL PROTECTED] writes: I have a program that I have the is supposed to run forever. I log any output to a log file. It is run in a startup script like thie: program_name $err_log 21 The problem is that after newsyslog rotates the $err_log file, no more data is written to the file. I can not stop and restart the program. I can accept a signal. But what do I need to do in program_name to allow the data to be written after the rotation of the file. There is not much you can do unless you modify your program to write directly to the log file instead of stdout (in which case you just need to re-open the log file when you get a SIGHUP), or use something like Apache's logrotate instead of newsyslog (pipe the program's output to logrotate, which takes care of the rest) Or, as an alternative to Apache's logrotate, there is multilog from djb's daemontools package - ports/sysutils/daemontools, http://cr.yp.to/daemontools.html G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 because I didn't think of a good beginning of it. pgp0.pgp Description: PGP signature
Re: Install problem
On Tue, Dec 23, 2003 at 12:44:01PM -0500, soupman wrote: Hello. I am getting the following error when attempting an FTP install from a Windows machine: Cannot parse information file for the bin distribution: I/O error. Please verify that your media is valid and try again. How did you originally put the files on the Windows machine? Are they on a CD there, or did you download them from some FTP site? If you downloaded them via FTP, is it possible that you have downloaded them in ASCII, not binary, mode? If this is so, the files would be corrupted, since the FTP transfer in ASCII mode would have placed a lot of CR characters before every LF character in the file, and those are definitely not needed (and harmful) for the binary tar/gzip archives used for the FreeBSD distribution. In short, if you originally downloaded the files from some FreeBSD mirror via FTP, you'll have to fetch them again, this time telling your FTP client to use binary, not ASCII, mode for the transfer. Hope this helps. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the meaning of this sentence. pgp0.pgp Description: PGP signature
Re: getpwnam with md5 encrypted passwds
On Wed, Nov 26, 2003 at 02:21:04PM +0100, Kai Mosebach wrote:
-Urspr?ngliche Nachricht-
Von: Terry Lambert [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 26. November 2003 13:34
An: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Betreff: Re: getpwnam with md5 encrypted passwds
[EMAIL PROTECTED] wrote:
i am trying to validate a given user password against my local passwd-
file with
this piece of code :
if (!( pwd = getpwnam ( user ))) {
log(ERROR,User %s not known,user);
stat=NOUSER;
}
if (!strcmp( crypt(pass,pwd-pw_name), pwd-pw_passwd) ) {
log(DEBUG|MISC,HURRAY : %s authenticated\n, user);
stat = AUTHED;
}
I know you have the fix for the crypt of the wrong field, but the
proper thing to do is probably to use pan_authenticate() so that
you are insensitive to the athentication method being used, rather
than crypting and comparing it yourself.
Looks interesting ... is this method also usable, when i dropped my privs ?
I think Terry meant pam_authenticate() (not pan), but to answer your
question: no, when you drop your privileges, you do not have access to
at least the system's password database (/etc/spwd.db, generated from
/etc/passwd and /etc/master.passwd by pwd_mkdb(8)). If this will be any
consolation, getpwnam() won't return a password field when you have
dropped root privileges either.
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This sentence contains exactly threee erors.
pgp0.pgp
Description: PGP signature
Re: interrupt statistics
On Fri, Nov 21, 2003 at 08:49:52AM +0100, Dag-Erling Sm?rgrav wrote: [EMAIL PROTECTED] (Dag-Erling Sm?rgrav) writes: Peter Pentchev [EMAIL PROTECTED] writes: Awwighty, attached is a patch that converts getuptime() and dointr() to use sysctl, and then adds the -a option to display all interrupts. This one was tested on both RELENG_4 and HEAD (ref5) :) [...] Why don't you use sysctlbyname(3) instead of juggling with numeric names? Point taken. I was going to attach a patch that uses sysctlbyname(3), fixes another buglet in the !VMSTAT_SYSCTL case (and is less intrusive), and removes the intrcnt/intrnames-related namelist definitions for the VMSTAT_SYSCTL case. However, it seems to have issues on 64-bit platforms, or at least beast. I'm working on it. I'll send a separate reply to your other message about the '???' and stray irq's. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence claims to be an Epimenides paradox, but it is lying. pgp0.pgp Description: PGP signature
Re: interrupt statistics
On Fri, Nov 21, 2003 at 09:56:40AM +0100, Dag-Erling Sm?rgrav wrote:
Peter Pentchev [EMAIL PROTECTED] writes:
Point taken. I was going to attach a patch that uses sysctlbyname(3),
fixes another buglet in the !VMSTAT_SYSCTL case (and is less intrusive),
and removes the intrcnt/intrnames-related namelist definitions for the
VMSTAT_SYSCTL case. However, it seems to have issues on 64-bit
platforms, or at least beast. I'm working on it.
Never mind, I'll take it from here. I've been working on it for the
past hour and have a ton of additional patches. There are other
issues to address such as the fact that your patch breaks post-mortem
use, and the desirability of removing vmstat's setgid bit.
I was thinking about the setgid bit too, but it can only be removed when
all of vmstat's functionality, not just dointr(), is converted to use
sysctl. That was the next item on my todo list :)
Still, here's the updated patch I was speaking of, just to show you what
I meant about the !VMSTAT_SYSCTL buglet and it being less intrusive;
kvm_openfiles() was not invoked even in the !VMSTAT_SYSCTL case, meaning
dointr() wouldn't work at all then.
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
Thit sentence is not self-referential because thit is not a word.
Index: src/usr.bin/vmstat/Makefile
===
RCS file: /home/ncvs/src/usr.bin/vmstat/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- src/usr.bin/vmstat/Makefile 8 Feb 2002 23:07:36 - 1.9
+++ src/usr.bin/vmstat/Makefile 20 Nov 2003 15:51:53 -
@@ -3,6 +3,7 @@
PROG= vmstat
MAN= vmstat.8
+CFLAGS+=-DVMSTAT_SYSCTL
BINGRP=kmem
BINMODE=2555
DPADD= ${LIBKVM} ${LIBDEVSTAT}
Index: src/usr.bin/vmstat/vmstat.8
===
RCS file: /home/ncvs/src/usr.bin/vmstat/vmstat.8,v
retrieving revision 1.25
diff -u -r1.25 vmstat.8
--- src/usr.bin/vmstat/vmstat.8 14 Apr 2003 07:22:25 - 1.25
+++ src/usr.bin/vmstat/vmstat.8 20 Nov 2003 15:51:53 -
@@ -41,7 +41,7 @@
.Sh SYNOPSIS
.Nm
.\ .Op Fl fimst
-.Op Fl fimsz
+.Op Fl afimsz
.Op Fl c Ar count
.Op Fl M Ar core
.Op Fl N Ar system
@@ -62,6 +62,10 @@
.Pp
The options are as follows:
.Bl -tag -width indent
+.It Fl a
+When used with
+.Fl i ,
+include statistics about interrupts that have never been generated.
.It Fl c
Repeat the display
.Ar count
Index: src/usr.bin/vmstat/vmstat.c
===
RCS file: /home/ncvs/src/usr.bin/vmstat/vmstat.c,v
retrieving revision 1.69
diff -u -r1.69 vmstat.c
--- src/usr.bin/vmstat/vmstat.c 9 Nov 2003 20:39:56 - 1.69
+++ src/usr.bin/vmstat/vmstat.c 21 Nov 2003 08:24:52 -
@@ -129,6 +129,7 @@
struct vmmeter sum, osum;
intwinlines = 20;
+intaflag = 0;
intnflag = 0;
kvm_t *kd;
@@ -174,8 +175,11 @@
memf = nlistf = NULL;
interval = reps = todo = 0;
maxshowdevs = 2;
- while ((c = getopt(argc, argv, c:fiM:mN:n:p:stw:z)) != -1) {
+ while ((c = getopt(argc, argv, ac:fiM:mN:n:p:stw:z)) != -1) {
switch (c) {
+ case 'a':
+ aflag++;
+ break;
case 'c':
reps = atoi(optarg);
break;
@@ -239,6 +243,9 @@
if (nlistf != NULL || memf != NULL)
setgid(getgid());
+#ifdef VMSTAT_SYSCTL
+ if (todo ~INTRSTAT) {
+#endif /* VMSTAT_SYSCTL */
kd = kvm_openfiles(nlistf, memf, NULL, O_RDONLY, errbuf);
if (kd == 0)
errx(1, kvm_openfiles: %s, errbuf);
@@ -258,6 +265,9 @@
warnx(kvm_nlist: %s, kvm_geterr(kd));
exit(1);
}
+#ifdef VMSTAT_SYSCTL
+ }
+#endif /* VMSTAT_SYSCTL */
if (todo VMSTAT) {
struct winsize winsize;
@@ -386,8 +396,26 @@
static time_t now;
time_t uptime;
- if (boottime.tv_sec == 0)
+ if (boottime.tv_sec == 0) {
+#ifdef VMSTAT_SYSCTL
+ int mib[2] = { CTL_KERN, KERN_BOOTTIME };
+ char *value;
+ size_t size;
+
+ if (sysctl(mib, 2, NULL, size, NULL, NULL) == -1)
+ err(1, sysctl(kern.boottime));
+ if (size sizeof(boottime))
+ errx(1, sizeof(kern.boottime) sizeof(timeval));
+ value = malloc(size);
+ if (value == NULL)
+ errx(1, malloc);
+ if (sysctl(mib, 2, value, size, NULL, NULL) == -1)
+ err(1, sysctl(kern.boottime));
+ memcpy(boottime, value, sizeof(boottime));
+#else /* VMSTAT_SYSCTL */
kread(X_BOOTTIME
Re: interrupt statistics
On Fri, Nov 21, 2003 at 12:13:46PM +0100, Dag-Erling Sm?rgrav wrote: Peter Pentchev [EMAIL PROTECTED] writes: I was thinking about the setgid bit too, but it can only be removed when all of vmstat's functionality, not just dointr(), is converted to use sysctl. I know; I'm working on it, and am more than half done. Still, here's the updated patch I was speaking of, just to show you what I meant about the !VMSTAT_SYSCTL buglet and it being less intrusive; kvm_openfiles() was not invoked even in the !VMSTAT_SYSCTL case, meaning dointr() wouldn't work at all then. VMSTAT_SYSCTL is a mistake; vmstat must decide at runtime whether to use sysctl (live system) or libkvm (postmortem). Oh; right. Sorry. Should have picked that up from your last message about the postmortem analysis. By the way, the '???' comes directly from i386/isa/mp_machdep.c, the update_intrname() routine; looks like there has never been a device driver or anything that has claimed interrupt 0 :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If there were no counterfactuals, this sentence would not have been paradoxical. pgp0.pgp Description: PGP signature
Re: integer and long max/min values
On Fri, Nov 21, 2003 at 09:53:50AM -0800, [EMAIL PROTECTED] wrote: [format recovered; Tim Kientzle wrote:] Jay Sern Liew wrote: how do I find out the maximum (and minimum) value a long and int will hold in C? (before it overflows or underflows) #include limits.h INT_MAX and INT_MIN are the max/min values for an int LONG_MAX and LONG_MIN are the max/min values for long. Also, see stdint.h, which is defined in C99. Also, buy a good C reference book. ;-) Tim Kientzle [..and Vijay Singh wrote:] Write a simple C program to ++ an int or long variable and see when it overflows. Why, after Tim actually quoted the exact header file to include and the exact constants to use? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 You have, of course, just begun reading the sentence that you have just finished reading. pgp0.pgp Description: PGP signature
Re: interrupt statistics
On Thu, Nov 20, 2003 at 05:49:45AM +0100, Erik Trulsson wrote:
On Wed, Nov 19, 2003 at 11:13:03PM -0500, Mike Tancsa wrote:
Speaking of which, why is it some devices are not always present
(same with systat -vmstat)
eg on one machine
v2% vmstat -i
interrupt total rate
stray irq7 2 0
hifn0 irq10 15680 0
fxp0 irq11 259067 2
mux irq15 378597 3
atkbd0 irq1 1 0
sio0 irq4 178 0
clk irq0 11466632 99
rtc irq8 14677398127
Total26797555233
yet on another,
offsite# vmstat -i
interrupt total rate
fxp0 irq11 29547828 61
mux irq15 453753 0
sio0 irq4 177 0
clk irq0 48204090 99
rtc irq8 61701185127
Total 139907033290
offsite#
offsite# dmesg | grep hifn
hifn0 mem 0xe9802000-0xe9802fff,0xe9801000-0xe9801fff irq 10 at device
0.0 on pci1
hifn0: Hifn 7951, rev 0, 128KB sram, 193 sessions
offsite#
How come the hifn does not show up ? I have noticed this with other
devices as well
vmstat -i only displays those devices that have generated interrupts.
I.e. if some device would have the total number of interrupts as 0, it
will not be show by vmstat -i
You will note that in your listings above, all the devices displayed
have generated at least one interrupt.
This is easily fixed, e.g. by the attached. Note that I've only tested
the RELENG_4 patch, my 5.x machine is out of commission for the next few
days :( (and no, I couldn't test it on ref5 for obvious reasons related
to /dev/mem ;)
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
because I didn't think of a good beginning of it.
Index: src/usr.bin/vmstat/vmstat.8
===
RCS file: /home/ncvs/src/usr.bin/vmstat/vmstat.8,v
retrieving revision 1.25
diff -u -r1.25 vmstat.8
--- src/usr.bin/vmstat/vmstat.8 14 Apr 2003 07:22:25 - 1.25
+++ src/usr.bin/vmstat/vmstat.8 20 Nov 2003 12:23:59 -
@@ -41,7 +41,7 @@
.Sh SYNOPSIS
.Nm
.\ .Op Fl fimst
-.Op Fl fimsz
+.Op Fl afimsz
.Op Fl c Ar count
.Op Fl M Ar core
.Op Fl N Ar system
@@ -62,6 +62,10 @@
.Pp
The options are as follows:
.Bl -tag -width indent
+.It Fl a
+When used with
+.Fl i ,
+include statistics about interrupts that have never been generated.
.It Fl c
Repeat the display
.Ar count
Index: src/usr.bin/vmstat/vmstat.c
===
RCS file: /home/ncvs/src/usr.bin/vmstat/vmstat.c,v
retrieving revision 1.69
diff -u -r1.69 vmstat.c
--- src/usr.bin/vmstat/vmstat.c 9 Nov 2003 20:39:56 - 1.69
+++ src/usr.bin/vmstat/vmstat.c 20 Nov 2003 12:24:28 -
@@ -129,6 +129,7 @@
struct vmmeter sum, osum;
intwinlines = 20;
+intaflag = 0;
intnflag = 0;
kvm_t *kd;
@@ -174,8 +175,11 @@
memf = nlistf = NULL;
interval = reps = todo = 0;
maxshowdevs = 2;
- while ((c = getopt(argc, argv, c:fiM:mN:n:p:stw:z)) != -1) {
+ while ((c = getopt(argc, argv, ac:fiM:mN:n:p:stw:z)) != -1) {
switch (c) {
+ case 'a':
+ aflag++;
+ break;
case 'c':
reps = atoi(optarg);
break;
@@ -756,7 +760,7 @@
rate);
inttotal = 0;
while (--nintr = 0) {
- if (*intrcnt)
+ if (*intrcnt || (aflag intrname[0]))
(void)printf(%-*s %20lu %10lu\n, istrnamlen, intrname,
*intrcnt, *intrcnt / uptime);
intrname += strlen(intrname) + 1;
@@ -829,7 +833,7 @@
usage()
{
(void)fprintf(stderr, %s%s,
- usage: vmstat [-imsz] [-c count] [-M core] [-N system] [-w wait]\n,
+ usage: vmstat [-aimsz] [-c count] [-M core] [-N system] [-w wait]\n,
[-n devs] [disks]\n);
exit(1);
}
Index: src/usr.bin/vmstat/vmstat.8
===
RCS file: /home/ncvs/src/usr.bin/vmstat/vmstat.8,v
retrieving revision 1.16.2.5
diff -u -r1.16.2.5 vmstat.8
--- src/usr.bin/vmstat/vmstat.8 16 Aug 2001 13:17:13 - 1.16.2.5
+++ src/usr.bin/vmstat/vmstat.8 20 Nov 2003 12:21:23 -
@@ -41,7 +41,7 @@
.Sh SYNOPSIS
.Nm
.\ .Op Fl fimst
-.Op Fl imsz
+.Op Fl aimsz
.Op Fl c Ar count
.Op Fl M Ar core
.Op Fl N Ar system
@@ -61,6 +61,10 @@
.Pp
The options
Re: interrupt statistics
On Thu, Nov 20, 2003 at 02:59:55PM +0100, Dag-Erling Sm?rgrav wrote:
Peter Pentchev [EMAIL PROTECTED] writes:
This is easily fixed, e.g. by the attached. Note that I've only tested
the RELENG_4 patch, my 5.x machine is out of commission for the next few
days :( (and no, I couldn't test it on ref5 for obvious reasons related
to /dev/mem ;)
Hmm, vmstat should uses sysctls, not /dev/mem. Perhaps you can make a
patch for that too? :)
Awwighty, attached is a patch that converts getuptime() and dointr() to
use sysctl, and then adds the -a option to display all interrupts.
This one was tested on both RELENG_4 and HEAD (ref5) :)
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
This would easier understand fewer had omitted.
? src/usr.bin/vmstat/.depend
? src/usr.bin/vmstat/vmstat
? src/usr.bin/vmstat/vmstat.8.gz
Index: src/usr.bin/vmstat/Makefile
===
RCS file: /home/ncvs/src/usr.bin/vmstat/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- src/usr.bin/vmstat/Makefile 8 Feb 2002 23:07:36 - 1.9
+++ src/usr.bin/vmstat/Makefile 20 Nov 2003 15:33:37 -
@@ -3,6 +3,7 @@
PROG= vmstat
MAN= vmstat.8
+CFLAGS+=-DVMSTAT_SYSCTL
BINGRP=kmem
BINMODE=2555
DPADD= ${LIBKVM} ${LIBDEVSTAT}
Index: src/usr.bin/vmstat/vmstat.8
===
RCS file: /home/ncvs/src/usr.bin/vmstat/vmstat.8,v
retrieving revision 1.25
diff -u -r1.25 vmstat.8
--- src/usr.bin/vmstat/vmstat.8 14 Apr 2003 07:22:25 - 1.25
+++ src/usr.bin/vmstat/vmstat.8 20 Nov 2003 15:33:37 -
@@ -41,7 +41,7 @@
.Sh SYNOPSIS
.Nm
.\ .Op Fl fimst
-.Op Fl fimsz
+.Op Fl afimsz
.Op Fl c Ar count
.Op Fl M Ar core
.Op Fl N Ar system
@@ -62,6 +62,10 @@
.Pp
The options are as follows:
.Bl -tag -width indent
+.It Fl a
+When used with
+.Fl i ,
+include statistics about interrupts that have never been generated.
.It Fl c
Repeat the display
.Ar count
Index: src/usr.bin/vmstat/vmstat.c
===
RCS file: /home/ncvs/src/usr.bin/vmstat/vmstat.c,v
retrieving revision 1.69
diff -u -r1.69 vmstat.c
--- src/usr.bin/vmstat/vmstat.c 9 Nov 2003 20:39:56 - 1.69
+++ src/usr.bin/vmstat/vmstat.c 20 Nov 2003 15:33:37 -
@@ -129,6 +129,7 @@
struct vmmeter sum, osum;
intwinlines = 20;
+intaflag = 0;
intnflag = 0;
kvm_t *kd;
@@ -174,8 +175,11 @@
memf = nlistf = NULL;
interval = reps = todo = 0;
maxshowdevs = 2;
- while ((c = getopt(argc, argv, c:fiM:mN:n:p:stw:z)) != -1) {
+ while ((c = getopt(argc, argv, ac:fiM:mN:n:p:stw:z)) != -1) {
switch (c) {
+ case 'a':
+ aflag++;
+ break;
case 'c':
reps = atoi(optarg);
break;
@@ -239,24 +243,26 @@
if (nlistf != NULL || memf != NULL)
setgid(getgid());
- kd = kvm_openfiles(nlistf, memf, NULL, O_RDONLY, errbuf);
- if (kd == 0)
- errx(1, kvm_openfiles: %s, errbuf);
- setgid(getgid());
-
- if ((c = kvm_nlist(kd, namelist)) != 0) {
- if (c 0) {
- warnx(undefined symbols:);
- for (c = 0;
- c (int)(sizeof(namelist)/sizeof(namelist[0]));
- c++)
- if (namelist[c].n_type == 0)
- (void)fprintf(stderr, %s,
- namelist[c].n_name);
- (void)fputc('\n', stderr);
- } else
- warnx(kvm_nlist: %s, kvm_geterr(kd));
- exit(1);
+ if (todo ~INTRSTAT) {
+ kd = kvm_openfiles(nlistf, memf, NULL, O_RDONLY, errbuf);
+ if (kd == 0)
+ errx(1, kvm_openfiles: %s, errbuf);
+ setgid(getgid());
+
+ if ((c = kvm_nlist(kd, namelist)) != 0) {
+ if (c 0) {
+ warnx(undefined symbols:);
+ for (c = 0;
+ c (int)(sizeof(namelist)/sizeof(namelist[0]));
+ c++)
+ if (namelist[c].n_type == 0)
+ (void)fprintf(stderr, %s,
+ namelist[c].n_name);
+ (void)fputc('\n', stderr);
+ } else
+ warnx(kvm_nlist: %s, kvm_geterr(kd));
+ exit(1
Re: interrupt statistics
On Thu, Nov 20, 2003 at 05:36:55PM +0200, Peter Pentchev wrote:
On Thu, Nov 20, 2003 at 02:59:55PM +0100, Dag-Erling Sm?rgrav wrote:
Peter Pentchev [EMAIL PROTECTED] writes:
This is easily fixed, e.g. by the attached. Note that I've only tested
the RELENG_4 patch, my 5.x machine is out of commission for the next few
days :( (and no, I couldn't test it on ref5 for obvious reasons related
to /dev/mem ;)
Hmm, vmstat should uses sysctls, not /dev/mem. Perhaps you can make a
patch for that too? :)
Awwighty, attached is a patch that converts getuptime() and dointr() to
use sysctl, and then adds the -a option to display all interrupts.
This one was tested on both RELENG_4 and HEAD (ref5) :)
Oops; a little buglet (deleted one character too many) in the HEAD patch
for the !VMSTAT_SYSCTL case. New HEAD patch attached.
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
because I didn't think of a good beginning of it.
Index: src/usr.bin/vmstat/Makefile
===
RCS file: /home/ncvs/src/usr.bin/vmstat/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- src/usr.bin/vmstat/Makefile 8 Feb 2002 23:07:36 - 1.9
+++ src/usr.bin/vmstat/Makefile 20 Nov 2003 15:51:53 -
@@ -3,6 +3,7 @@
PROG= vmstat
MAN= vmstat.8
+CFLAGS+=-DVMSTAT_SYSCTL
BINGRP=kmem
BINMODE=2555
DPADD= ${LIBKVM} ${LIBDEVSTAT}
Index: src/usr.bin/vmstat/vmstat.8
===
RCS file: /home/ncvs/src/usr.bin/vmstat/vmstat.8,v
retrieving revision 1.25
diff -u -r1.25 vmstat.8
--- src/usr.bin/vmstat/vmstat.8 14 Apr 2003 07:22:25 - 1.25
+++ src/usr.bin/vmstat/vmstat.8 20 Nov 2003 15:51:53 -
@@ -41,7 +41,7 @@
.Sh SYNOPSIS
.Nm
.\ .Op Fl fimst
-.Op Fl fimsz
+.Op Fl afimsz
.Op Fl c Ar count
.Op Fl M Ar core
.Op Fl N Ar system
@@ -62,6 +62,10 @@
.Pp
The options are as follows:
.Bl -tag -width indent
+.It Fl a
+When used with
+.Fl i ,
+include statistics about interrupts that have never been generated.
.It Fl c
Repeat the display
.Ar count
Index: src/usr.bin/vmstat/vmstat.c
===
RCS file: /home/ncvs/src/usr.bin/vmstat/vmstat.c,v
retrieving revision 1.69
diff -u -r1.69 vmstat.c
--- src/usr.bin/vmstat/vmstat.c 9 Nov 2003 20:39:56 - 1.69
+++ src/usr.bin/vmstat/vmstat.c 20 Nov 2003 15:53:00 -
@@ -129,6 +129,7 @@
struct vmmeter sum, osum;
intwinlines = 20;
+intaflag = 0;
intnflag = 0;
kvm_t *kd;
@@ -174,8 +175,11 @@
memf = nlistf = NULL;
interval = reps = todo = 0;
maxshowdevs = 2;
- while ((c = getopt(argc, argv, c:fiM:mN:n:p:stw:z)) != -1) {
+ while ((c = getopt(argc, argv, ac:fiM:mN:n:p:stw:z)) != -1) {
switch (c) {
+ case 'a':
+ aflag++;
+ break;
case 'c':
reps = atoi(optarg);
break;
@@ -239,24 +243,26 @@
if (nlistf != NULL || memf != NULL)
setgid(getgid());
- kd = kvm_openfiles(nlistf, memf, NULL, O_RDONLY, errbuf);
- if (kd == 0)
- errx(1, kvm_openfiles: %s, errbuf);
- setgid(getgid());
-
- if ((c = kvm_nlist(kd, namelist)) != 0) {
- if (c 0) {
- warnx(undefined symbols:);
- for (c = 0;
- c (int)(sizeof(namelist)/sizeof(namelist[0]));
- c++)
- if (namelist[c].n_type == 0)
- (void)fprintf(stderr, %s,
- namelist[c].n_name);
- (void)fputc('\n', stderr);
- } else
- warnx(kvm_nlist: %s, kvm_geterr(kd));
- exit(1);
+ if (todo ~INTRSTAT) {
+ kd = kvm_openfiles(nlistf, memf, NULL, O_RDONLY, errbuf);
+ if (kd == 0)
+ errx(1, kvm_openfiles: %s, errbuf);
+ setgid(getgid());
+
+ if ((c = kvm_nlist(kd, namelist)) != 0) {
+ if (c 0) {
+ warnx(undefined symbols:);
+ for (c = 0;
+ c (int)(sizeof(namelist)/sizeof(namelist[0]));
+ c++)
+ if (namelist[c].n_type == 0)
+ (void)fprintf(stderr, %s,
+ namelist[c].n_name);
+ (void)fputc('\n', stderr);
+ } else
Re: kernel enviroment in sysctl MIB
On Tue, Nov 11, 2003 at 06:01:55PM +0100, Reinier Kleipool wrote: Hello, I am investigating the possiblilies for looking at the kernel boot parameters from within a userland utility. (Possibly a new FreeBSD install facility) The idea is that by looking at sysctl kern.environment.* you should be able to see the BTX variables. An install program could use this to see an INSTALL_SERVER=install.company.com variable (etc...) to use as install server. The BTX loader could provide these variables at install boot time, thus enableing fully automated installs. [snip] My question is this: When looking at kern/kern_environmet.c I see routines that install a SYSCTL_NODE kern.environment. The sysctl_kernenv routine handles this node. What I do not understand is how the environment is returned from this routine. Take a look at the kenv(1) utility - its source is in the src/usr.bin/kenv/kenv.c file. There is a weird comment at line 74, where the kern.environment sysctl is accessed in a really 'magic undocumented' way. Look at what it does - basically enumerating oid's from a given starting point, the starting point being obtained in said 'magic undocumented' way - and see if you could use the same approach. Alternatively, you could just invoke kenv(1) with your variables as command-line parameters from your program/script, although this might incur a performance cost. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI pgp0.pgp Description: PGP signature
Re: kernel enviroment in sysctl MIB
On Wed, Nov 12, 2003 at 05:00:54PM +0200, Peter Pentchev wrote: On Tue, Nov 11, 2003 at 06:01:55PM +0100, Reinier Kleipool wrote: Hello, I am investigating the possiblilies for looking at the kernel boot parameters from within a userland utility. (Possibly a new FreeBSD install facility) The idea is that by looking at sysctl kern.environment.* you should be able to see the BTX variables. An install program could use this to see an INSTALL_SERVER=install.company.com variable (etc...) to use as install server. The BTX loader could provide these variables at install boot time, thus enableing fully automated installs. [snip] My question is this: When looking at kern/kern_environmet.c I see routines that install a SYSCTL_NODE kern.environment. The sysctl_kernenv routine handles this node. What I do not understand is how the environment is returned from this routine. Take a look at the kenv(1) utility - its source is in the src/usr.bin/kenv/kenv.c file. Errr, of course, if you're working with FreeBSD 5.x after 2003/01/20, that would be src/bin/kenv/kenv.c :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Nostalgia ain't what it used to be. pgp0.pgp Description: PGP signature
Re: RFC: proposed new builtin for /bin/sh (associative arrays)
On Fri, Oct 31, 2003 at 01:43:31AM -0800, Luigi Rizzo wrote:
[snip description of a new 'indexes' builtin]
Any comments ? Is this interesting enough to be committed
(with a proper manpage description) ?
I could provide a flag to indexes to return the values instead
of the names, but i believe this form is more useful.
Just a minor suggestion: could this be done as another form of variable
expansion instead of as another keyword? Rationale: bash already does
this - from the 'EXPANSION' section of its manpage:
${!prefix*}
Expands to the names of variables whose names begin with prefix,
separated by the first character of the IFS special variable.
Thus, 'indexes foo_' would be equivalent to '${!foo_*}'.
What you've done is great - several times I've found myself wishing that
our sh had this, especially after finding that bash does it - but
wouldn't it be better not to introduce a gratuitious syntax
incompatibility if we can help it? :)
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If this sentence were in Chinese, it would say something else.
pgp0.pgp
Description: PGP signature
Re: rsync vs installworld
On Sun, Oct 19, 2003 at 10:16:54AM -1000, Clifton Royston wrote: Date: Sat, 18 Oct 2003 19:28:27 -0600 (MDT) From: M. Warner Losh [EMAIL PROTECTED] Subject: rsync vs installworld Message-ID: [EMAIL PROTECTED] I'm contemplating a binary distribution system for some systems that I have. I'm ignoring kernel updates for the moment, and concentrating on userland deployment. I'm thinking of doing something like: make buildworld make installworld DESTDIR=/big/disk/freebsd/image make mergemaster -D /big/disk/freebsd/mergemaster And then on each machine I want to update I'd do something like: sudo rsync --exclude etc --exclude usr/local --exclude boot \ --delete -av host-server:/big/disk/freebsd/image / sudo rm -rf /tmp/mergemaster sudo scp host-server:/big/disk/freebsd/mergemaster /tmp/mergemaster sudo mergemaster -someargs My question is: has anybody else tried this? If so, what bumps along the way are there going to be? I'm also very interested in this topic, as we're about to try to get something similar working. Initially it will be for a moderate number of servers at one location, and so can require console intervention, but in our case it eventually needs to extend to many systems located elsewhere with no onsite administrator. In our case we have already built a simple framework for distributing FreeBSD binary packages built within the ports system (rsync presently, but extensible to http/https.) I have been hoping that it's possible to build on the make release approach to generate a set of binary packages for updates to the base system, distribute those via rsync, and then install the package collection. It seems to me that an advantage of that approach is that one could incorporate some of that mergemaster logic into the pkg-install scripts. Feedback, direction, or real-world experience with like systems would be welcomed. Errr, isn't this pretty much what Colin Percival's security/freebsd-update port already does? :) Take a look at http://www.daemonology.net/freebsd-update/ - this might be exactly what you are looking for... G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence would be seven words long if it were six words shorter. pgp0.pgp Description: PGP signature
Re: rsync vs installworld
On Mon, Oct 20, 2003 at 07:41:51AM +0100, Colin Percival wrote: At 09:19 20/10/2003 +0300, Peter Pentchev wrote: On Sun, Oct 19, 2003 at 10:16:54AM -1000, Clifton Royston wrote: In our case we have already built a simple framework for distributing FreeBSD binary packages built within the ports system ^^ (rsync presently, but extensible to http/https.) I have been hoping that it's possible to build on the make release approach to generate a set of binary packages for updates to the base system, distribute those via rsync, and then install the package collection. Errr, isn't this pretty much what Colin Percival's security/freebsd-update port already does? :) FreeBSD Update doesn't handle the ports tree. That said, as long as one wishes to track the release branch of base, there's no reason not to use FreeBSD Update + portupgrade. This wasn't an option for the original poster (imp@) because he wanted to track -stable. Guess I should've expanded a bit on my ideas here :) What I meant was not that they should use your excellent service as it is, but that they might try to duplicate its functionality - use your tools, the binary diff and the update script, to produce their own update sets for the base system. For the ports tree, well, there is already ports/sysutils/portupgrade which, combined with a reasonably recent INDEX rebuild and a central package repository for packages built using either the package-recursive target or scripts similar to those in ports/Tools/scripts/pkg-stash/, should be a good way to manage package deployment across multiple hosts. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 because I didn't think of a good beginning of it. pgp0.pgp Description: PGP signature
Re: Darwin/OSX Bluetooth code
On Thu, Oct 16, 2003 at 09:00:02PM -0700, Maksim Yevmenkin wrote: [snip] I'm currently thinking about un-Netgraph'ing FreeBSD code to make it portable to other BSD style systems. I'm trying to look at other implementations and learn as much as i can. In particular i'm trying to figure out how to minimize OS dependent code and what is the right abstractions levels. When I saw your BlueTooth entry in the recent status report, I thought I'd comment on that, but then got distracted :) You've done some great work on BlueTooth. IMHO, it would be a mistake to try to un-NetGraph it; there have been lots of rumours about people porting the NetGraph framework to other OS's, and if BlueTooth support will provide yet one more reason for the need to do this, so be it :) NetGraph is a wonderful framework for writing drivers, and not limited to network drivers, either - as you have no doubt discovered so far - there should be no need to give up its advantages if it's possible to retain them and even gain much in portability for the writing of future drivers (should NetGraph run on more OS's). G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence was in the past tense. pgp0.pgp Description: PGP signature
Re: crypt
On Thu, Oct 16, 2003 at 11:37:37AM +, omestre wrote: Hello, i need authenticate users in a FreeBSD environment and linux environment. My passwords are stored with FreeBSD crypt format. We wrote a pam module to authenticate the users, but if the module runs in FreeBSD and obvious (crypt bsd)... works. In linux does not. Have a simple way to write a simple crypt function to my linux module, that behaves like the FreeBSD libc crypt function? Then i will bypass the two libc crypt *imcompatibilities*... Sorry by the english. Linux has a crypt(3) function, too, and it usually works. You'll need to tell us a bit more than 'in linux does not' - what exactly does not work? My first guess would be that you cannot compile or load your module, because either the linker or the loader tells you that the 'crypt' symbol is undefined. In that case, try giving the -lcrypt option to the linker, to tell it to use the libcrypt library - some Linux distributions keep their crypt(3) in a separate library. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI pgp0.pgp Description: PGP signature
Re: user malloc from kernel
On Mon, Sep 29, 2003 at 05:04:05PM -0700, Brian O'Shea wrote: --- Peter Pentchev [EMAIL PROTECTED] wrote: [actually, Pawel wrote this:] Here you got sample kernel module which do this: http://garage.freebsd.pl/usmalloc.tgz http://garage.freebsd.pl/usmalloc.README [and then I replied] E... but won't this interfere *badly* with userland programs which attempt to allocate memory after making the syscall in question? Couldn't the user library interface to this new system call just malloc() the memory first in the process, and then pass the pointer and size to the kernel via the system call interface? This would ensure that malloc() doesn't touch the desired range of memory until it is freed by the user. You'd just have to be careful not to free it until the kernel is done with it. This would be my preferred solution, too, although it might mean that when you are not exactly sure of how much memory the kernel will need, you either overallocate and pass a max-size argument (see most of the socket calls like accept(2), getsockname(2), getpeername(2), etc), or you do two syscalls, one for determining the size needed, and another for actually copying the data (see sysctl(3)). The second approach is more robust, but it does have the overhead of an additional syscall and might also possibly be vulnerable to a race (if the data should change between the two invocations). This, of course, could be worked around by having another couple of syscalls for locking and unlocking the data - lock, query size, fetch, unlock - but that would open a whole new can of worms :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If wishes were fishes, the antecedent of this conditional would be true. pgp0.pgp Description: PGP signature
Re: user malloc from kernel
On Mon, Sep 29, 2003 at 05:47:41PM +0200, Pawel Jakub Dawidek wrote: On Mon, Sep 29, 2003 at 05:22:47PM +0300, earthman wrote: + how to allocate some memory chunk + in user space memory from kernel code? + how to do it correctly? Here you got sample kernel module which do this: http://garage.freebsd.pl/usmalloc.tgz http://garage.freebsd.pl/usmalloc.README E... but won't this interfere *badly* with userland programs which attempt to allocate memory after making the syscall in question? I mean, won't the application's memory manager attempt to allocate the next chunk of memory right over the region that you have stolen with this brk(2) invocation? Thus, when the application tries to write into its newly-allocated memory, it will overwrite the data that the kernel has placed there, and any attempt to access the kernel's data later will fail in wonderfully unpredictable ways :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 No language can express every thought unambiguously, least of all this one. pgp0.pgp Description: PGP signature
Re: Mirror Plex (Raid 1) after installing FreeBSD
On Tue, Sep 16, 2003 at 07:08:13PM +0300, Murat USTUNTAS wrote: Hello, I read documents on Vinum for FreeBSD. But, some points exculed.. I want to find some points on Vinum.. If I have identical 2 disks (Samsung SP6300 Series),suppose, I want to install the FreeBSD on one of them 60 Gb. After installing the FreeBSD , I want to run vinum with mirroring with whole disk. How can I configure like situation.. Isn't this exactly what is covered by the 'Bootstrapping Vinum' article? http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/vinum/ G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This inert sentence is my body, but my soul is alive, dancing in the sparks of your brain. pgp0.pgp Description: PGP signature
Re: if bpf fd's select()able?
On Sun, Sep 07, 2003 at 04:04:49PM -0700, Lev Walkin wrote: Dmitry Morozovsky wrote: Dear colleagues, [all below is for 4-STABLE] I'm trying to write effective arp scanner for multi-interface router (esp. multi-vlan); I plan to use multiple bpf devices attached to different interfaces emitting ARP requests and filters listening to ARP replies; the most natural way to multiplex them for me is select(). However, my tests show that select()ing bpf fd does not lead to trigger packets available to bpf filter; the process hangs in select state while parallel tcpdump process shows packets desired *and* is in bpf state. Am I missing something base? References (surely, I'd already read manpages for bpf, pcap and related -- but did I still missed something serious?) would be greatly appreciated. Yes, you're missing the interactive mode. Refer to BIOCIMMEDIATE in the bpf(4) manual page. Also, I believe that for a month or so bpf devices have been able to issue kqueue notifications, too, so - at least for FreeBSD - the most natural way might now be kqueue() and not select() :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If wishes were fishes, the antecedent of this conditional would be true. pgp0.pgp Description: PGP signature
Re: non reliable nmi
On Thu, Sep 04, 2003 at 09:16:23AM -0400, Don Bowman wrote: From: Mike Silbersack [mailto:[EMAIL PROTECTED] On Thu, 28 Aug 2003, Don Bowman wrote: I have machdep.ddb_on_nmi=1. I can drop into the debugger with the magic key sequence. However, when i hit the NMI jumper, i don't always go there. Sometimes I do. The system is 4-way SMP [2xHTT xeon processors] with 4.7. Any suggestion on where my NMI might be going? Is your NMI about 106K in size, and does it have the subjects Thank you, Wicked screensaver and others? If so, I think I know where it's going... ? it was actually a serious question. The nmi header on my board goes into the ICH-3 of my chipset, but shorting the jumper out doesn't always enter the debugger. It does sometimes. If I set the NMI_NOW bit in the ICH-3 I always enter the debugger. I was curious if anyone else had seen this behaviour. I haven't kept quite up to date on my x86 hardware lately (read: in the past five to ten years), but I distinctly remember a time when everyone referred to x86's NMI as a joke: a non-maskable interrupt that anyone could mask using a simple CLI instruction. Not sure if this is still the case, others would have to say if today's processors still may get so wedged that a NMI request would simply be ignored. The other possibility is some kind of kernel mess-up, bad enough that an NMI does indeed reach the processor, the processor does invoke the NMI handler, yet the handler (DDB) is quite unable to actually do any useful work - messed up data structures and such. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence no verb. pgp0.pgp Description: PGP signature
Re: ucom not in MAKEDEV in 4.8-STABLE
On Thu, Aug 07, 2003 at 11:05:30AM +1000, JacobRhoden wrote: Hi People, I was wondering, is there a reason why the 4.8-STABLE version of MAKEDEV does not have the ability to generate ucom. (I was wondering because I have to back port a bit of code on every machine I want to do it on). Err, are you sure you mean -STABLE, and not -RELEASE here? ucom was added to -STABLE's MAKEDEV three weeks ago, in rev. 1.243.2.57 by Kris Kennaway. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? pgp0.pgp Description: PGP signature
Re: complicated downgrade
On Sat, Jul 19, 2003 at 08:48:40AM -0700, LLeweLLyn Reese wrote:
Valentin Nechayev [EMAIL PROTECTED] writes:
[snip]
8. Disable all processes except sshd and run the following (saying generally):
for D in /bin /sbin /etc /boot /usr/bin /usr/sbin /usr/lib /usr/libexec \
/usr/libdata /usr/share /usr/local /var/db
do
mv ${D} ${D}5
mv ${D}4 {D}
done
[snip]
Once you mv /usr/lib /usr/lib5, dynamicly linked executables will be
broken, until you mv /usr/lib4 /usr/lib (I think). I think it
would be a good idea check every tool you think you might need,
and build a staticly linked executable if the existing executable
isn't. Most of what you need will be staticly linked by default,
but e.g. sshd, ftp, find, vim, are not. (If all goes as planned,
you won't need any of those while /usr/lib is being moved, but
... ) (Caveat: this isn't based on experience with freebsd, it's
based experience with linux boxen, where *everything* is typically
staticly linked, unless someone rebuilt tools.)
This thought occurred to me too; actually, you could get around this
problem by rebuilding the whole FreeBSD base system with purely static
binaries. This could be done by putting NOSHARED=yes in /etc/make.conf,
then going through the buildworld/buildkernel/installkernel/installworld
dance. You might have to do this for your 5.x world, reboot with the
statically-linked binaries (just in case), build the 4.x world with
NOSHARED=yes before the downgrade, do the downgrade (without having to
worry about any dynamic libs), then, when the 4.x system is working
(hopefully), rebuild the 4.x world without the NOSHARED=yes setting.
Note that a NOSHARED world tends to take up quite a bit more space :)
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
I've heard that this sentence is a rumor.
pgp0.pgp
Description: PGP signature
Re: raw socket programming SOLVED
On Mon, Jul 07, 2003 at 10:09:05AM -0500, David A. Gobeille wrote: [snip] Shouldn't the #included files themselves #include headers they are dependant on? With the use of #ifndef and #define in the headers to keep them from being #included more than once? It seems silly(more work) for the programmer to have to arrange everything in a specific order. Search the list archives for 'promiscuous includes'; I believe this has been discussed time and again over the years :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence would be seven words long if it were six words shorter. pgp0.pgp Description: PGP signature
Re: tcsh / tset problem on 4.7 only?
On Mon, Jul 07, 2003 at 12:02:43PM -0400, Leo Bicknell wrote: I have a script that I've been using since the dawn of time that seems to fail on 4.7-RELEASE boxes, but not on anything before or after. To duplicate: Run the stock (/bin/tcsh) tcsh binary, and do: % eval `tset -s -Q` Missing ]. [snip] I checked the cvs logs for both /etc/termcap, and for tset, and see nothing that would have changed between those releases. I even looked briefly at csh aka tcsh, and saw nothing obvious. Anyone have any idea why this is broken on 4.7? What terminal are you using? Could you post the 'runme' file resulting from the 'tset -s -Q' command? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence every third, but it still comprehensible. pgp0.pgp Description: PGP signature
Re: replacing sendmail with qmail
On Fri, Jun 27, 2003 at 09:39:36AM +0200, Soeren Straarup wrote: Well my point is that every one (that is interrested in security) knows that Sendmail and bind and so on have their exploits.. And I like that they are the one that is comming with some more or less insecure services, this is due to that it really gives ppl the freedom choose the services that they want to use. But the generic ones works for home networks with no external access too. Freedom of religion. Well with freedom comes responsibility. And this responsibility is handled excellently by the FreeBSD Security Officer team and the FreeBSD sendmail maintainer, George Shapiro. I don't think that there would be a better way to handle the existing and published Sendmail vulnerabilities than the current practice of timely patches and updates to both -current, -stable, *and* the various security branches, so that everyone tracking the security advisories is aware of the need to update, and update *now*, as soon as there is actually something to update to. Great job, folks! With that said, you could always do what I do and cut your own releases with appropriate NO_* knobs in make.conf ;) This is *not* to say that I don't trust the security officer team and the maintainers of the various pieces of contributed software that I exclude from my own builds; it's just a matter of personal preference. Here's hoping this is the last post in this thread :) (The last word? Me? Naah, that's just lack of morning coffee getting to you :P ) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence was in the past tense. pgp0.pgp Description: PGP signature
Re: ports and /var/db/pkg
On Fri, Apr 04, 2003 at 02:11:58PM +0300, Danny Braniss wrote: ok, so i wrote a small script (tcl, since i don't know perl), that does some checking, it reports for each package, the number of files how many are realy there, and if so, checks the MD5. now, if im not to far off, if some/all files are missing, or if the md5 does not match, i should be able to remove the package info, ... Well, that's not what you were asking for originally, and tools already exist to check that. OK, let me refrase it PROBLEM: how to update /var/db/pkg, when it knows too much, i.e. /usr/local has less stuff that /var/db/pkg knows about. e.g. pkg_info -g and the example from the pkg_which(1) manpage that I mentioned to you in a previous email. i read most of the pkg*, and though im very impressed, i fail to find a clear/easy way to get a one line output saying: pkg xyz no longer exits, can be removed from database If you are only interested in packages which no longer have *any* files on the filesystem, then compare the output of the following two commands: pkg_info -qL package | wc -l pkg_info -qg package | wc -l If the output of those two commands is the same, then there are no valid package files left at all, and a pkg_delete -f is in order. Moreover, if you are only interested in the existence of the files, it would be easier to do something like: remove=1 pkg_info -qL package | while read fname; do [ -f $fname ] remove=0 done if [ $remove == 1 ]; then pkg_delete package; fi G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 yields falsehood, when appended to its quotation. yields falsehood, when appended to its quotation. pgp0.pgp Description: PGP signature
Re: ports and /var/db/pkg
On Fri, Apr 04, 2003 at 04:14:19PM +0300, Peter Pentchev wrote: On Fri, Apr 04, 2003 at 02:11:58PM +0300, Danny Braniss wrote: ok, so i wrote a small script (tcl, since i don't know perl), that does some checking, it reports for each package, the number of files how many are realy there, and if so, checks the MD5. now, if im not to far off, if some/all files are missing, or if the md5 does not match, i should be able to remove the package info, ... Well, that's not what you were asking for originally, and tools already exist to check that. OK, let me refrase it PROBLEM: how to update /var/db/pkg, when it knows too much, i.e. /usr/local has less stuff that /var/db/pkg knows about. e.g. pkg_info -g and the example from the pkg_which(1) manpage that I mentioned to you in a previous email. i read most of the pkg*, and though im very impressed, i fail to find a clear/easy way to get a one line output saying: pkg xyz no longer exits, can be removed from database If you are only interested in packages which no longer have *any* files on the filesystem, then compare the output of the following two commands: pkg_info -qL package | wc -l pkg_info -qg package | wc -l If the output of those two commands is the same, then there are no valid package files left at all, and a pkg_delete -f is in order. Moreover, if you are only interested in the existence of the files, it would be easier to do something like: remove=1 pkg_info -qL package | while read fname; do [ -f $fname ] remove=0 done if [ $remove == 1 ]; then pkg_delete package; fi Just one more comment: the reason I stick to pkg_delete -f instead of rm -rf /var/db/pkg/package is that the /var/db/pkg scheme is not really set in stone: the correct way to manipulate the package database is *only* via the pkg_* tools. Well, there is something to be said about the tools available in ports/sysutils/portupgrade, but then, they are actively maintained by knu, who will most probably track any changes in the base system handling of packages, if and when those should occur. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? pgp0.pgp Description: PGP signature
Re: ports and /var/db/pkg
On Thu, Apr 03, 2003 at 02:06:39PM +0300, Danny Braniss wrote: Correct. ok, so i wrote a small script (tcl, since i don't know perl), that does some checking, it reports for each package, the number of files how many are realy there, and if so, checks the MD5. Errr.. you mean, it does something like 'pkg_info -g'? :) now, if im not to far off, if some/all files are missing, or if the md5 does not match, i should be able to remove the package info, ... Q: true or false? What do you mean, 'remove the package info'? What exactly are you trying to achieve? G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Thit sentence is not self-referential because thit is not a word. pgp0.pgp Description: PGP signature
Re: make world + kernel with gcc 3.2?
On Sat, Mar 15, 2003 at 07:58:13PM +, Scott Mitchell wrote: On Sat, Mar 15, 2003 at 07:08:40PM +0100, Thierry Herbelot wrote: Le Saturday 15 March 2003 18:14, Avleen Vig a ?crit : I don't expect HUGE problems with making world, but am I asking for trouble if I make a new kernel with GCC3.2? good luck to you ! just have a look at the differences in the source code between current and stable to enable the compilation of current with gcc3 (FriBi -Stable will not compile with anything other than gcc 2.95) TfH I assume the OP installed gcc3 from ports...in this case the gcc2.95 system compiler will still be installed as well. True. I'm pretty sure that a kernel build will explicitly use the system compiler, True. and buildworld/buildkernel certainly do (I believe buildworld actually builds a fresh copy of gcc2.95 then uses that to build the rest of the system). True. As Thierry says, trying to build -stable with gcc3 is probably doomed to failure. Correct, but irrelevant, as shown above. The buildworld/buildkernel process will use the system gcc 2.95.x, and everything will go smoothly. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. pgp0.pgp Description: PGP signature
Re: variable size too large?
On Fri, Mar 14, 2003 at 03:37:29PM +0100, Ferruccio Vitale wrote: Hi all, I'm writing a little multithread program: in my thread function, I allocated a char variable of IP_MAXPACKET size; when I try to compile it, everything goes well, but when I run it, it dies, making a core file. Assume that: 1) the same code, with only one thread, linked to libc, runs normally 2) the same code, with a smaller variable size, linked to libc_r, runs normally 3) I tried to allocate two variables of 64000 bytes in this function (IP_MAXPACKET is equal to 65535), linked to libc_r and runs normally Where am I wrong? :)) It would be very hard to say, without seeing your program and, if possible, the output of a gdb session which shows where exactly the program dies. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If you think this sentence is confusing, then change one pig. pgp0.pgp Description: PGP signature
