Re: Doubt of system(3)
On Sat, Sep 29, 2001 at 11:28:39PM +0100, David Taylor wrote:
[snip]
IMO, the below patch is probably the best solution.
Yep, it also fixes the fact that the return value from wait4() needs
to be preserved, at least for the return statement of __system().
G'luck,
Peter
--
yields falsehood, when appended to its quotation. yields falsehood, when appended to
its quotation.
cvs diff: Diffing .
Index: system.c
===
RCS file: /home/ncvs/src/lib/libc/stdlib/system.c,v
retrieving revision 1.7
diff -u -r1.7 system.c
--- system.c2001/01/24 13:00:59 1.7
+++ system.c2001/09/29 21:55:41
@@ -53,7 +53,7 @@
__system(command)
const char *command;
{
- pid_t pid;
+ pid_t pid, savedpid;
int pstat;
struct sigaction ign, intact, quitact;
sigset_t newsigblock, oldsigblock;
@@ -86,8 +86,9 @@
execl(_PATH_BSHELL, sh, -c, command, (char *)NULL);
_exit(127);
default:/* parent */
+ savedpid = pid;
do {
- pid = _wait4(pid, pstat, 0, (struct rusage *)0);
+ pid = _wait4(savedpid, pstat, 0, (struct rusage *)0);
} while (pid == -1 errno == EINTR);
break;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: setjmp/longjmp
On Mon, Oct 01, 2001 at 10:56:24AM +0930, Greg Lehey wrote: [Format recovered--see http://www.lemis.com/email/email-format.html] On Friday, 28 September 2001 at 10:12:14 -0700, Julian Elischer wrote: On Fri, 28 Sep 2001, Gersh wrote: On Fri, 28 Sep 2001, Bernd Walter wrote: On Fri, Sep 28, 2001 at 07:03:51PM +0530, Anjali Kulkarni wrote: Does anyone know whether it is advisable or not to use setjmp/longjmp within kernel code? I could not see any setjmp/longjmp in kernel source code. Is there a good reason for this or can it be used? You need to look again, it's used in several places in the kernel. Look at sys/i386/i386/db_interface.c Yeah but it would probably be a pretty bad idea to use it without very careful thought. Especialy with the kernel becoming pre-emptable in the future.. Can you think of a scenario where it wouldn't work? Preemption doesn't tear stacks apart, right? How about a case of a longjmp() back from under an acquired lock/mutex? Like function A sets up a jump buffer, calls function B, B acquires a lock, B calls C, C longjmp()'s back to A; what happens to the lock? It would work if A were aware of B's lock and the possibility of a code path that would end up with it still being held; I presume that this is what Julian meant by 'very careful thought'. G'luck, Peter -- Do you think anybody has ever had *precisely this thought* before? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Planet
On Thu, Sep 27, 2001 at 04:44:31PM +0200, Martin Vana wrote: Hi, I tried to rebuilt my kernel with device rl0 (NIC PLANET ENW-9503A based on REALTEK 8139 chip) it has collapsed during make phase. It cannot find files starting with mii* but they are present. Is it that it cannot find the files, or functions from those files? If it's functions that it cannot find, try adding 'device miibus' to your kernel, like the comments in LINT say (rl is listed under 'PCI Ethernet NICs that use the common MII bus controller code'). If it is the files themselves - are you sure you have re-run config(8) after changing your kernel configuration file? To be absolutely certain, run config with the -r flag to remove any old directories. To be *really* certain, use the buildworld/buildkernel way. G'luck, Peter -- I've heard that this sentence is a rumor. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Does boot1 still have a 1023 cyl limit?
Hi, A quote from the end of the boot_i386.8 manual page.. IMPORTANT NOTE: Because of limitations imposed by the conventional disk interface provided by the BIOS, all boot-related files and structures (including the kernel) that need to be accessed during the boot phase must reside on the disk at or below cylinder 1023 (as the BIOS under- stands the geometry). When a ``Disk error 0x1'' is reported by the sec- ond-stage bootstrap, it generally means that this requirement has not been adhered to. Just today I had a friend ask me if this is still true; I checked CVS history and found out that this comment was added by rnordier more than two years ago. Is this still true? G'luck, Peter -- If you think this sentence is confusing, then change one pig. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Does boot1 still have a 1023 cyl limit?
On Fri, Sep 14, 2001 at 09:50:23AM -0700, Mike Smith wrote: A quote from the end of the boot_i386.8 manual page.. IMPORTANT NOTE: Because of limitations imposed by the conventional disk interface provided by the BIOS, all boot-related files and structures (including the kernel) that need to be accessed during the boot phase must reside on the disk at or below cylinder 1023 (as the BIOS under- stands the geometry). When a ``Disk error 0x1'' is reported by the sec- ond-stage bootstrap, it generally means that this requirement has not been adhered to. Just today I had a friend ask me if this is still true; I checked CVS history and found out that this comment was added by rnordier more than two years ago. Is this still true? No; it's quite possible now to boot from beyond the 1024 cylinder mark, however boot0 does not install in 'packet' mode by default, which means that you need to manually install/configure it before rebooting after system installation. So we don't cleanly install for 1024 cylinders, but it works with a little tweaking. So.. if I read you right, booting correctly for 1024 cylinders works if boot0 knows about it. Isn't boot0 the one in the MBR, not in the fbsd slice? Does this mean that boot1 and boot2 should work just fine if they are loaded by another kind of MBR loader (say, Grub), and they find out that they are placed beyond the 1023th cylinder? G'luck, Peter -- Nostalgia ain't what it used to be. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Question about what programs to use in /etc/rc*
On Sun, Sep 09, 2001 at 06:06:01PM -0400, Adrian Filipi-Martin wrote:
On Sun, 9 Sep 2001, Ulf Zimmermann wrote:
These are some examples strings:
dhcp
dhcp media 10baseTX
media 10baseTX dhcp mediaopt half-duplex
The following code will get me inside a if condition:
if [ `expr ${ifconfig_args} : '.*[Dd][Hh][Cc][Pp].*'` -ne 0 ]; then
fi
You do everything you need within sh. Someone else pointed out
that case/esac is your friend here. It was not quite complete. Here's
more complete example that will let you pair up the options and their
arguments if they take them.
ifconfig_args=media 10baseTX dhcp mediaopt half-duplex
set -- ${ifconfig_args}
while [ $# -gt 0 ]; do
op=$1
case ${op} in
[Mm][Ee][Dd][Ii][Aa])
op_arg=$2
shift
echo op=media op_arg=${op_arg}
;;
I don't like this. This second-guessing of ifconfig(8)'s arguments
is prone to error - consider the case of a new keyword added to
ifconfig(8).. And blindly discarding unrecognized keyword would
not really work either - a new keyword might take an argument,
the shell script has no way of knowing that, so it would skip
the keyword and try to look at its argument as another keyword;
what if a keyword takes a string argument of, oh, say, 'dhcp'? :)
A ${args#dhcp} might work better, but there is a problem with it -
the # match is case-sensitive, and I *know* that there are people
using 'dhcp' and people using 'DHCP' :)
G'luck,
Peter
--
This would easier understand fewer had omitted.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Question about what programs to use in /etc/rc*
On Mon, Sep 10, 2001 at 09:35:24AM -0700, Ulf Zimmermann wrote:
On Mon, Sep 10, 2001 at 06:19:54PM +0300, Peter Pentchev wrote:
Come to think of it, it might be as easy as: [**UNTESTED**]
case ${ifconfig_args}; in
[Dd][Hh][Cc][Pp]*)
set $ifconfig_args
shift
ifconfig_add_args=$*
..
..provided there is a requirement that the ifconfig_args should *start*
with 'dhcp' (which would be easy enough to meet - right now, the args
have to *be* 'dhcp', so any additional arguments would be stapled on at
the end).
This sounds as the best solution. This would allow to set an interface
to be DHCP (variable dhcp_interfaces get set) and take the rest of the
arguments (like media/mediaopt) and apply them to the interface before
the dhclient gets started.
If you decide to do it this way, make sure you do not make the same
mistake I did - set $ifconfig_args is *very* much unsafe; better
try set -- $ifconfig_args, as in Adrian's message to which I repled :)
G'luck,
Peter
--
I am not the subject of this sentence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
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-hackers in the body of the message
Re: Permissions on /root directory and /etc/mtree/BSD.root.dist
On Thu, Sep 06, 2001 at 08:23:34PM +0100, void wrote: On Thu, Sep 06, 2001 at 10:30:08AM +0400, Andrey Simonenko wrote: 0700 mode restricts other users from reading /root directory. When root wants to upgrade system he/she run make buildworld, make installworld. But installworld calls mtree, which changes /root permissions to default value specified in the /etc/mtree/BSD.root.dist file. So, if administrator will not forgot about needed permissions on /root, then installworld will open /root directory for reading for everybody. I propose not to change permissions on /root directory in the /etc/mtree/BSD.root.dist file and leave them unchanged. Comments? There is a whole class of problems like this. For example, my installation of mutt doesn't work right if /var/mail is not mode 1777, but BSD.var.dist changes it to 755 every time I installworld. I think a more general solution might be in order. Perhaps some sort of local.dist that is processed after BSD.*.dist. As a workaround, I put chmod 1777 /var/mail in my rc.local script. I suggest you do something similar. And then, of course, there is the obvious solution: maintaining some local patches, applied to the source tree after each update. (and reversed before each update..) This is the way I'm doing it, but then, I have a *lot* of local changes, and such an approach might not make sense for a single change like that.. G'luck, Peter -- I am the thought you are now thinking. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: local changes to CVS tree
On Wed, Sep 05, 2001 at 01:10:27PM +0200, Alexander Langer wrote: Thus spake Kris Kennaway ([EMAIL PROTECTED]): On Wed, Sep 05, 2001 at 09:52:34AM +0300, Giorgos Keramidas wrote: I have it fixed now in my local CVS tree. Hopefully Kris will commit something to fix it soon :-) I'm just curious: How do people fix stuff in their local CVS tree and sync other FreeBSD changes with that? I mean I have much stuff, which gets M file in the next cvs update, but I'd really like to cvs commit them to my local /home/ncvs, but cvsup will overwrite these changes. One way that (I think it was) Sheldon pointed out to me a few months ago would be keeping your own CVS repository and vendor-importing the FreeBSD source on a regular basis. The regular vendor-import is quite time-consuming though :( Also, I'm not really sure if CVS would allow having two vendor branches (say, RELENG_4 and RELENG_5) and two corresponding working branches (your changes to RELENG_4 and your changes to RELENG_5, which might be *way* different). G'luck, Peter -- Thit sentence is not self-referential because thit is not a word. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: virtual consoles
On Mon, Sep 03, 2001 at 12:04:45PM +0200, Gunnar Olsson wrote: Hi, To increase number of xterms I thought. only the option MAXCONS could be changed. But even though I change it from 16 to 32, I still only get 16. Someone there who can give me I quick answer? I think this is the same issue that came up with a friend of mine just today. Actually, you do have 32 consoles; you just cannot switch to them using the function keys. The Alt-Fx combinations are only defined for 16 consoles (you have to use Alt-Shift-F[3-6] for the last four). Extending this would plough straight into the key definitions for the function keys themselves, which would be a Bad Thing (tm). You still can get to the additional consoles by switching to ttyvf (Alt-Shift-F6) and repeatedly pressing PrintScreen to get to the next VC. I realize that this is probably not much help, but it might be a wise thing to step back and think if you really do need all that many VC's; my friend's reply was 'I like to watch logs', but this is easily done with screen(1) - ^A 0 to ^A 9 give you 10 terminals per VC :) 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-hackers in the body of the message
Re: installation problem
On Sun, Aug 26, 2001 at 11:35:49PM -0700, Rohit Panda wrote: hi , i was using linux and a great fan of it.Then i heard about this wonderful OS called FreeBSD and wanted to try it out.i thought to install it via FTP. My E: drive in my windows machine is the place where i want to install FreeBSD(i have formatted my E: ,but iam getting the chance to fdisk because Sysinstall is not running). But iam facing a problem during installation.i have made the images of the kern.flp and mfsroot.flp from windows using the utility fdimage.Then i booted from the kernel image floppy .Everything goes fine and after that when i put the other floppy and hit enter it says zf_read:unexpected EOF . Then it continues with the kernel configuration.Once i teied to configure and the next time i skipped,but after that comes the problem.after it probes it says Please wrap lines at 80 or less characters in the future. The problem you are seeing is most probably a corrupted floppy disk, or a corrupted image. Try writing the mfsroot.flp image to another disk, then if this fails, try downloading mfsroot.flp again. Oh, and btw, posting to freebsd-questions would have been *quite* enough :) G'luck, Peter -- This sentence claims to be an Epimenides paradox, but it is lying. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Problems with Squid on 4.4-RC
On Mon, Aug 27, 2001 at 12:05:39PM +0300, Vladimir Terziev wrote: Hi hackers, I've cvsuped with release tag RELENG_4 and I've considered that I had FreeBSD 4.4-RC. This is not a problem at all, but I've tried to install and run Squid-2.4-STABLE1. It has installed sucsessfuly. I've run it, but when a browser makes a request to it, the child which got the request exits with a signal 6 (ABRT I think). Does anybody have an idea what is the reason? Are you using the www/squid24 port? G'luck, Peter -- If you think this sentence is confusing, then change one pig. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: your mail
Now why do I have this uneasy feeling that you just fell for a spammer's email address collection bait.. G'luck, Peter -- If wishes were fishes, the antecedent of this conditional would be true. On Fri, Aug 24, 2001 at 08:42:17AM -0700, Laurence Berland wrote: From now on, please use the test@ email list for testing. None of us care if your Mail:: module works On Sat, 25 Aug 2001, Charlie Root wrote: Subject: Mail::Internet test subject This is a test message that was sent by the test suite of Mail::Internet. Testing. one From foo four From bar seven To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvsup RELENG_4 = 4.4-RC1 ?
On Sat, Aug 25, 2001 at 01:16:00AM -0700, Kris Kennaway wrote: On Sat, Aug 25, 2001 at 10:10:25AM +0200, Chojin wrote: Hello, I want to know if RELENG_4 will download 4.4-RC1 or lastest 4.3-STABLE files ? Because I don't want to be in 4.4-RC1, too many problems. The latest 4.3-STABLE *is* 4.4-RC. See the handbook for a full description of how FreeBSD branches work. Right, it is 4.4-RC, but it is NOT 4.4-RC1 - the snapshot that was released a few days ago. To answer the original poster's question: RELENG_4 will download the lated 4.3-STABLE files, which are a bit past the 4.4-RC1 snapshot. G'luck, Peter -- If there were no counterfactuals, this sentence would not have been paradoxical. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: function calls/rets in assembly
On Sat, Aug 25, 2001 at 03:44:27PM +0300, Valentin Nechayev wrote: Fri, Aug 24, 2001 at 11:36:45, jhb (John Baldwin) wrote about Re: function calls/rets in assembly: printasint: pushl %ebp movl %esp,%ebp subl $8,%esp addl $-8,%esp [...] Because this code is broken and obfuscated? :) We save %esp in %ebp (the only thing that keeps it from breaking) then for some reason allocate two quadwords on the stack unnecessarily, one using an add instruction, one using a sub. Because gcc has `-mpreferred-stack-boundary=4' default. Please read info gcc to realize what this option means. If you want to avoid this, compile with `-mpreferred-stack-boundary=2', as FreeBSD kernel is compiled. The only illogical thing here is that it doesn't gather two %esp moving instructions (one for frame of this function, one for frame for called function) to single one. [snip] Well, now you should add wanted options to /etc/make.conf and avoid seeing of such nightmares. I wonder if a mentioning of -mpreferred-stack-boundary should be added to tuning(7).. G'luck, Peter -- No language can express every thought unambiguously, least of all this one. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvsup RELENG_4 = 4.4-RC1 ?
On Sat, Aug 25, 2001 at 10:07:18AM -0500, Conrad Sabatier wrote: On 25-Aug-2001 Peter Pentchev wrote: On Sat, Aug 25, 2001 at 09:45:41AM -0500, Conrad Sabatier wrote: On 25-Aug-2001 Chojin wrote: Hello, I want to know if RELENG_4 will download 4.4-RC1 or lastest 4.3-STABLE files ? Because I don't want to be in 4.4-RC1, too many problems. Then you don't want to cvsup RELENG_4, I guess. More problems in 4.3-STABLE than in RC, actually. Hrm.. I thought Warner fixed some things in the PCI BIOS handling, Eric Melville fixed up some sysinstall issues, others MFC'd other important fixes.. What exactly are you referring to - problems that were introduced *since* 4.4-RC1? If so, what are those? Perhaps I wasn't clear enough here. I meant that he'd be better off with the release candidate than with an earlier stable. Well, RELENG_4 is still technically - or might be considered ;) - 4.x-STABLE, although 4.4-RC is a better description. So yes, I guess you're right - the 4.4-RC1 snapshot of the 4.4-RC period of the RELENG_4 branch (whee..) is a better choice than any snapshot of the 4.3-STABLE period of the RELENG_4 branch.. Okay, I'll shut up now :) G'luck, Peter -- yields falsehood, when appended to its quotation. yields falsehood, when appended to its quotation. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tunable support for ata interrupt sharing
On Tue, Aug 21, 2001 at 09:41:50PM +0200, Søren Schmidt wrote: It seems Brooks Davis wrote: Attached it a patch to make sharing of the main ata control interrupts dependent on a tunable, hw.ata.shared_irqs. This is required for my new HP Omnibook 500 to use the CMD 648 in the expansion base to work as it appears hardwired to interrupt 15 (which is fairly logical given that there is no where to attach devices to the secondary channel.) If this looks ok and you don't have time to deal with it, I'd be happy to commit it myself. I have just today committed always sharing all irq's to -current, the consensus is that if the BIOS allows sharing it should work. This makes sense, the MB maker is the only one that knows if this is working, if they blow it in thier BIOS, well Would this be good to have in 4.4? If Brooks's laptop needs it, it would be nice to have 4.4 run on that, too.. G'luck, Peter -- If you think this sentence is confusing, then change one pig. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 4.4-RC NFS panic
On Mon, Aug 20, 2001 at 12:27:24PM +0100, Walter C. Pelissero wrote:
[ it seems my original article didn't get through ]
I recently upgraded to 4.4-RC.
Now my Vaio panics when I use NFS volumes (as client).
The panic is reproducible with a:
find /some/NFS/mount/point -type f -exec cat {} \; /dev/null
Sometime I got a page fault, sometime a lockmgr: locking against myself
Here is a kgdb session:
[snip]
#7 0xc016dbfc in m_freem (m=0xc0738a00) at ../../kern/uipc_mbuf.c:618
#8 0xc0b59652 in ?? ()
#9 0xc0b66b92 in ?? ()
#10 0xc0b3fe37 in ?? ()
#11 0xc0b606de in ?? ()
#12 0xc0b5f11b in ?? ()
#13 0xc023b75d in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
All those ??'s are the result of kgdb being unable to look inside
a kernel module. Are you loading NFS as a module? What other modules
are loaded at the time of the panic? Could you try compiling them
statically into the kernel, see if the panic still happens, but with
more debugging information?
G'luck,
Peter
--
If this sentence didn't exist, somebody would have invented it.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Signal Handling
On Tue, Aug 14, 2001 at 09:11:58PM -0700, brian o'shea wrote: On Tue, Aug 14, 2001 at 07:47:50PM -0700, Hans Zaunere wrote: [...] 2) If a 10k binary is running, the signal is sent, and the program is reloaded from disk, but is 100k (or 1k even) how does the signal handling function get called, taking into account what Stevens says. Steven states that the sigmask remains for calls across exec, so wouldn't the wrong address to the handler function be used? No, the signal mask is not the address of the handler function. It is the bit mask which determines which signals are blocked. Sorry, I think I miss spoke myself. If a signal handler is setup in the running process, and exec is called, replacing the same program, but this time, the program is much smaller or bigger, will the signal handler function be in the right place? The same program is exec'd, but since it's a different size, won't the signal handler function pointer, point to the wrong place? If a program calls exec on the file that is the current text file (i.e. argv[0]), then the text segment of the process will be the same size as it was before the call to exec, because it will be identical. The only reason why the process' size might (and probably will) be different is because of any dynamically allocated memory, and because of and stack growth from function calls and local variable allocation. Neither of these effect the address of any of the functions in the program (including the signal handlers). This is not necessarily true; a program might exec() a file by the same name, but with different contents - e.g. restarting a recompiled server. G'luck, Peter -- I've heard that this sentence is a rumor. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Signal Handling
On Mon, Aug 13, 2001 at 09:09:32AM -0700, Hans Zaunere wrote: In a program that I am working on, I've decided to catch signal 15, which then calls execl() in the handler to reload the program from the on-disk binary. I am able to send it the signal, it reloads, and works fine. However I could not send the signal again and have the program respond. I then learned, with some help, that the signal needs to be unblocked after each call. It now works as intended. However in reading about this, in Steven's Advanced Programming in the UNIX Environment, he states: Naturally a signal that is being caught by a process that calls exec cannot be caught in the new program, since the address of the signal-catching function in the caller probably has no meaning in the new program file that is execed. Page. 273) This makes sense to me, however doesn't seem to be the case. Three questions: 1) Why, in the first place, does a signal become blocked after it is recieved? Why does the kernel want to do this? Mainly compatibility - it was done this way in some oold Unixen. The sigaction(2) syscall gives you much more control over how your handlers are called/reset/etc. 2) If a 10k binary is running, the signal is sent, and the program is reloaded from disk, but is 100k (or 1k even) how does the signal handling function get called, taking into account what Stevens says. Steven states that the sigmask remains for calls across exec, so wouldn't the wrong address to the handler function be used? The sigmask remains, but not the handlers themselves. Look at the execve(2) manual page - it explains exactly what is done to both signal handlers and the signal mask - the part about blocked signals is the one that talks about the signal mask. 3) Is my using of exec, in fact, the best way to reload the program on the fly, from within itself? What would be the best, robust, way to do this in the future? Executing your own image is a good way to do it. It does have some drawbacks, but it is a good way. I hope that when you exec something, you are really certain that it is your actual program that you are executing, and not just argv[0]. Otherwise, a malicious user might start your program with a different argv[0] setting (all exec*() functions allow this), then send a 'reload' signal/command/whatever, and have your program execute something else, possibly with elevated privileges. G'luck, Peter -- If I were you, who would be reading this sentence? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tuning the 4.1-R kernel for networking
On Tue, Aug 07, 2001 at 09:33:20PM -0700, Brian O'Shea wrote: Hello, I am using a PIII 550MHz UP system running FreeBSD 4.1-RELEASE. It has a 3c905B-TX Fast Etherlink XL card. # ifconfig xl0 xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 10.34.24.62 netmask 0xfc00 broadcast 10.34.27.255 inet6 fe80::2c0:4fff:fe20:3926%xl0 prefixlen 64 scopeid 0x1 ether 00:c0:4f:20:39:26 media: autoselect (100baseTX full-duplex) status: active supported media: autoselect 100baseTX full-duplex 100baseTX 10baseT/UTP full-duplex 10baseT/UTP 100baseTX hw-loopback Apart from Alfred's suggestions to up some sysctl values, I would suggest - specifically for 3c905* cards - to explicitly configure the interface media (add 'media 100baseTX' to your ifconfig line). You did not report any throughput problems, so this might not be a problem for you; still, it might be worth trying. G'luck, Peter -- Nostalgia ain't what it used to be. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ypbind malfunction on 4.x
I think that there has been quite a lot of work on ypbind recently. Try updating to 4.3-STABLE (actually 4.4-PRERELEASE now), there were several patches in that area in the past week or two. Or alternatively, wait for 4.4-RELEASE about the end of August. G'luck, Peter -- Do you think anybody has ever had *precisely this thought* before? On Tue, Aug 07, 2001 at 11:07:48AM -0400, Robert Withrow wrote: Hi: If I'm posting to the wrong list, please let me know. There is a long-running problem in FreeBSD's yp/ypbind that is evidenced by: Aug 4 02:01:43 tuva ypbind[160]: NIS server [192.32.150.15] for domain engeast not responding Aug 4 02:02:14 tuva last message repeated 30 times Aug 4 02:04:15 tuva last message repeated 121 times (And there would be other messages about throttling icmp messages, except I've applied a patch to ypbind.c that at least throttles things down to 1 message per second. This patch was posted to questions.) ... and it never rebinds to any other server. The only way I've found to fix the problem is to reboot. I am experiencing this in 4.3 Release, and I've had it in 4.2 and earlier. This problem has seen a little discussion in questions. But I've never seen anything in any of the lists about a solution to the core problem. Maybe I've missed this? Anyone working on this? It is a pretty serious problem (since you basically can't do anything once it happens in typical NIS/Amd installations). I'd appreciate, at least, knowing if there is a non-reboot work-around. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libmp
On Mon, Aug 06, 2001 at 12:33:40PM +, Eugene L. Vorokov wrote: Hello, I cvsup'ed 5.0-CURRENT yesterday, successfully compiled the kernel and tried to compile the rest. However, when doing make in the lib directory, it stops on libmp. The problem is that libmp uses include files from openssl/, and they are not present in my system, as I can see they don't come with freebsd. Of course I know how to install libssl, but is there any sense in using files that don't exist, so that user must install some third-party software to compile *distribution* component ? Or did my cvsup messed something up or am I missing something ? Er... the OpenSSL sources *are* shipped with FreeBSD. Or at least they should be, if your CVSup is doing the right thing. Are you cvsup'ping the src-all collection, or the subcollections? There is no longer any need to *not* cvsup src-all, no matter if you are in an export-controlled environment or not - all the export restrictions on code included with FreeBSD have either expired, or (ISTR) been waived specifically for the FreeBSD distribution. So.. cvsup again, using the src-all collection, and see if you grab the src/crypto/openssl/ and src/secure/lib/openssl/ bits. Also, make sure that NOSECURE is NOT turned on in your make.conf. Hope that helps.. G'luck, Peter -- This sentence was in the past tense. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libmp
On Mon, Aug 06, 2001 at 03:18:28PM +0300, Peter Pentchev wrote: On Mon, Aug 06, 2001 at 12:33:40PM +, Eugene L. Vorokov wrote: Hello, I cvsup'ed 5.0-CURRENT yesterday, successfully compiled the kernel and tried to compile the rest. However, when doing make in the lib directory, it stops on libmp. The problem is that libmp uses include files from openssl/, and they are not present in my system, as I can see they don't come with freebsd. Of course I know how to install libssl, but is there any sense in using files that don't exist, so that user must install some third-party software to compile *distribution* component ? Or did my cvsup messed something up or am I missing something ? Er... the OpenSSL sources *are* shipped with FreeBSD. Or at least they should be, if your CVSup is doing the right thing. Are you cvsup'ping the src-all collection, or the subcollections? There is no longer any need to *not* cvsup src-all, no matter if you are in an export-controlled environment or not - all the export restrictions on code included with FreeBSD have either expired, or (ISTR) been waived specifically for the FreeBSD distribution. So.. cvsup again, using the src-all collection, and see if you grab the src/crypto/openssl/ and src/secure/lib/openssl/ bits. Also, make sure that NOSECURE is NOT turned on in your make.conf. Of course, this should have been src/secure/lib/libssl/, but it is not really relevant in this case; src/secure/lib/libcrypto/ would be much more relevant :) G'luck, Peter -- If wishes were fishes, the antecedent of this conditional would be true. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libmp
On Mon, Aug 06, 2001 at 04:46:22PM +, Eugene L. Vorokov wrote: Er... the OpenSSL sources *are* shipped with FreeBSD. Or at least they should be, if your CVSup is doing the right thing. Are you cvsup'ping the src-all collection, or the subcollections? There is no longer any need to *not* cvsup src-all, no matter if you are in an export-controlled environment or not - all the export restrictions on code included with FreeBSD have either expired, or (ISTR) been waived specifically for the FreeBSD distribution. So.. cvsup again, using the src-all collection, and see if you grab the src/crypto/openssl/ and src/secure/lib/openssl/ bits. Also, make sure that NOSECURE is NOT turned on in your make.conf. Hope that helps.. Hmm yes, it's there. But the snapshot I installed first doesn't have it (why ?). When I installed it manually prior to compiling libs, libmp compiles fine ... Btw, is there any guide of what is the proper order of compiling things after cvsup ? Yep, the src/UPDATING file. What do you mean, the snapshot did not have it? Did you really CVSup 5.0-current on a machine running an earlier version, or did you install from a pre-built 5.0-current snapshot? Or are you referring to the CVSup snapshot - in what sense did it not have it - there was no src/crypto/openssl/ directory, or there was no src/secure/lib/libcrypto/ directory, or the libcrypto Makefile did not install the OpenSSL header files files under /usr/obj/.../src/i386/usr/include/openssl? How exactly are you trying to compile things? What did you do after the CVSup run? And.. what version are you updating from? G'luck, Peter -- Do you think anybody has ever had *precisely this thought* before? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libmp
On Mon, Aug 06, 2001 at 05:18:49PM +, Eugene L. Vorokov wrote: Hmm yes, it's there. But the snapshot I installed first doesn't have it (why ?). When I installed it manually prior to compiling libs, libmp compiles fine ... Btw, is there any guide of what is the proper order of compiling things after cvsup ? Yep, the src/UPDATING file. What do you mean, the snapshot did not have it? Did you really CVSup 5.0-current on a machine running an earlier version, or did you install from a pre-built 5.0-current snapshot? Or are you referring to the CVSup snapshot - in what sense did it not have it - there was no src/crypto/openssl/ directory, or there was no src/secure/lib/libcrypto/ directory, or the libcrypto Makefile did not install the OpenSSL header files files under /usr/obj/.../src/i386/usr/include/openssl? How exactly are you trying to compile things? What did you do after the CVSup run? And.. what version are you updating from? I first installed the snapshot 5.0-20010618-CURRENT. Then I installed cvsup and cvsup'ed src-all collection. When it was completed, I tried to recompile the kernel, Strike one - the kernel needs *at least* config(8) (as you already know), and it might need updated parts of the build toolchain. This would certainly fail. Read src/UPDATING for the proper procedure. but config was complaining that it's version doesn't match the kernel version, so I compiled and installed src/usr.sbin/config, then I configured and compiled kernel, it compiled fine. Strike two - config(8) and the kernel still might need updated parts of the toolchain (e.g. new assembly syntax). You are lucky it worked. Read src/UPDATING. Then I rebooted and tried to compile the userland things. I was thinking that I must first install new include files, then compile and install libs and then executables. Strike three - you are *almost* correct, but you ought to have first built the bootstrap tools, then used them to build a couple of other things, and only then move on to the include files. The 'buildworld' target takes care of all that in a very nice way. Read src/UPDATING :) So I did make and make install in the src/include directory and tried to do the same in the src/lib, but it stopped on libmp. The src/include directory does not hold all include files at all. Some of them are spread out in library directories, some of them are even spread out in program directories. The 'buildworld' target takes care of all that in a very nice way. Read src/UPDATING :) At that point I had no /usr/include/openssl directory at all, and no libs either. Right. The src/include Makefile does not handle src/secure/libcrypto. The 'buildworld'... oh well ;) Then I tried to compile src/secure/lib, but make there couldn't be completed too, because libcypher, which is compiled first, also was complaining about openssl library. I tried to compile src/secure/lib/libssl, it compiled successfully, but still it did not properly install all nesessary include files to /usr/include/openssl (only a few were installed), so I had to manually copy src/secure/lib/libssl/openssl/* to /usr/include/openssl/, after which I was able to compile the rest in src/secure/lib, the rest in src/secure and then, finally, src/lib. This sounds like you went to a *lot* of trouble just because you did not read the src/UPDATING file :) It is great that it finally worked, but.. it might have been easier :) I think the reason that my initial installation didn't have openssl could be that I just forgot to toggle the appropriate flag in the sysinstall, but still, IMHO this shouldn't make update process that tricky. Generally, I think Makefiles could be constructed to reflect those dependencies, no ? They are; just not the Makefiles in the directories you looked at, and not in the way you tried to do it. The 'buildworld' and 'buildkernel' targets were specifically made to handle this kind of dependencies when updating from a much earlier version of FreeBSD. And, why make install in the src/secure/lib/openssl only does this (first line wrapped so that mailer won't be confused with too long line): [snip make install output] There a lot of other include files it should copy ... As I mentioned in another email, src/secure/lib/openssl is not really relevant. src/secure/lib/libcrypto is much more important. Or must I compile something else too before I can simply type make in the src/secure/lib which will work ? And if so, then again, why isn't Makefile there written to compile things in a proper order ? The Makefile in that particular directory is written so as to be invoked by a higher-order Makefile that knows what dependencies ought to be satisfied, and what dependencies *have* already been satisfied. The Makefile in that particular directory is written so as to be able to be used when the rest of the tree is not really present, but only in a limited way. G'luck,
Re: Wierd IRQ Routing issues
On Thu, Aug 02, 2001 at 10:01:25PM +0200, lists wrote: Hi, hoping someone can help me out with something here, because Ive got a very strange problem. On my one pc, when assigning an IRQ to my PCIC device, it assigns an IRQ and continues, works 100% now that I changed device.hints to look for pcic on pci instead of isa, card works everything. However, on my other pc with an identical setup, when trying to assign pcic irq it does this: (from dmesg): pci_cfgintr_search: linked (3) to configured irq 10 at 0:9:0 pci_cfgintr: 0:10 INTA routed to irq 10 Now for some reason I have it in my head that that irq routing is broken, because its the only difference I can find between the non-working box and the working box. Is there any way that I can force that card to not use a routed interrupt like that. Ive already tried fiddling in my bios with the IRQ settings to reserve things etc, no luck there either. I know for a fact that irq 5/7/9/10/11 are all available on my box, with nothing taking them. Any ideas would be MUCH appreciated The second box wouldn't be a -stable machine, would it now? I think PCIC IRQ routing was absolutely not working in -stable as of a few weeks ago, when Warner Losh started MFC'ing the PCIC bits. That MFC might not be complete yet. If both boxes are running -current, I'll just shut up :) G'luck, Peter -- This would easier understand fewer had omitted. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Accessing /dev/klog and similar
On Mon, Jul 30, 2001 at 02:35:21PM -0700, Kris Kennaway wrote: On Mon, Jul 30, 2001 at 11:50:18AM -0700, Hans Zaunere wrote: Hello, I'm looking to access kernel messages directly from the kernel, and not through syslog if I can help it. Look at how syslogd does it. Or rather, do not try this while syslogd is running. src/sys/kern/subr_log.c defines the operation of the /dev/klog device, and there is an upper limit on the number of processes that can simultaneously open the log device - the limit is one. That is, while syslogd is running, no other process can open the klog device for reading. This seems to have been the case ever since rev. 1.1 of src/sys/kern/subr_log.c; that is, this has been the case in 4.4BSD and earlier. Anybody have any recollection on why the kernel won't let more than one process intercept log messages (aside from the obvious fact that stacked syslogd's could easily DoS a machine)? G'luck, Peter -- because I didn't think of a good beginning of it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: perhaps one of phk's intern projects?
On Fri, Jul 27, 2001 at 10:58:55AM -0400, Louis A. Mamakos wrote: Matthew Emmerton([EMAIL PROTECTED])@2001.07.26 16:50:52 +: On Thu, 26 Jul 2001, Matthew Jacob wrote: It'd be nice if one could pass a time specification to at in the form of next reboot. -matt Why not just write a script for the command and stick it in /usr/local/etc/rc.d? because a uid != 0 won't write a startup file there, won't he? ;-) Of course, he could use the crontab(1) command, and install an entry with a time of '@reboot'. RTFM: man 1 crontab man 5 crontab Sure, this starts something on *every* reboot, but that's the same as if you installed someting in /usr/local/etc/rc.d [CC list trimmed viciously] So cron allows a @reboot specification, but at(1) (which is invoked by cron, btw - but that's an implementation detail) does not? This seems like lack of parallelism.. IMHO, there's nothing wrong in adding that functionality to at(1). If people don't like it, they won't use it :) G'luck, Peter -- This sentence was in the past tense. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: custom release / custom install.cfg
On Fri, Jul 27, 2001 at 03:45:02PM -0500, crg wrote: hackers: I built my own custom release and created a custom install.cfg file. The file is good because I tested with a FreeBSD 4.3Release. And it partitions my disk and installs the a custom bin distro. Now for my custom release, I deleted all bin.?? files and inserted some of my own files and directories in the R/cdrom/disc2 filesystem. Next, I created one big bin.aa file ~ 60M since I am going burn a CD. It works fine (partitions the disk) until it trys to Extracting bin into / It hangs there. Yes debugging in the install.cfg file is set to yes and after I hit Alt-F2, the messages are not helpful at all. The last line reads: DEBUG Trying for piece 1 of 1: bin/bin.aa I redid all the md5 checksums in CHECKSUM.MD5 and edited bin.inf. Can I just create another bin.?? file with my files and add it to the bin.inf and do the md5 checksum against it. And just add it to the bin directory on the iso image? Or is this foul? I haven't tried replacing the bin.* files with one big file, but I think that this might be your problem: sysinstall might be trying to allocate memory for each chunk, and fail to allocate a 60MB chunk all at once. Could you try splitting your bin dist into a lot of smaller files, just as the original distribution does, and see if that works? G'luck, Peter -- If wishes were fishes, the antecedent of this conditional would be true. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: crunched binary oddity
On Tue, Jul 24, 2001 at 10:14:09AM -0700, Etienne de Bruin wrote: Greetings. I crunchgen'd newfs and linked mount_mfs to it (among many other progs), compiled it with success. And yet when I boot my MFS kernel and try to mount /tmp to mfs, boot_crunch complains that 'mfs' is not compiled into it? My /etc/fstab: /dev/zero /tmpmfs rw,nosuid,-s=262144,-m=0,-T=minimum 0 0 /dev/zero /varmfs rw,-s=262144,-m=0,-T=minimum 0 0 /dev/cd0c /cdrom cd9660 ro,user 0 0 proc/proc procfs rw 0 0 Go on, give it to me. Could it be that it's not boot_crunch, but the kernel complaining? What is the exact error message? G'luck, Peter -- If I were you, who would be reading this sentence? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ARP cache problems....
On Thu, Jul 26, 2001 at 02:11:21PM +0400, Maxim Konovalov wrote: On Thu, 26 Jul 2001, Eugene L. Vorokov wrote: Anybody know how to turn them off ? sysctl net.link.ether.inet.log_arp_wrong_iface ? vel@bugz:/home/vel # sysctl net.link.ether.inet.log_arp_wrong_iface sysctl: unknown oid 'net.link.ether.inet.log_arp_wrong_iface' Huh ? $ rlog -r1.74 if_ether.c ... description: revision 1.74 date: 2001/01/06 00:45:08; author: alfred; state: Exp; lines: +8 -1 provide a sysctl 'net.link.ether.inet.log_arp_wrong_iface' to allow one to supress logging when ARP replies arrive on the wrong interface: /kernel: arp: 1.2.3.4 is on dc0 but got reply from 00:00:c5:79:d0:0c on dc1 the default is to log just to give notice about possibly incorrectly configured networks. This exists in -current and has been MFC'd before 4.3-RELEASE. FreeBSD installations older than 4.3-RELEASE, or -STABLE installations older than January 6, 2001, would not have this sysctl knob. G'luck, Peter -- The rest of this sentence is written in Thailand, on To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: perhaps one of phk's intern projects?
On Thu, Jul 26, 2001 at 10:20:51AM -0700, Matthew Jacob wrote: It'd be nice if one could pass a time specification to at in the form of next reboot. This could be implemented as a startup script, no? On second thoughts, not quite trivial. It wouldn't be hard to write a separate utility to schedule jobs to be serviced at the next reboot; integrating this functionality into at(1) would be nice, too, though maybe just a little bit harder - it would require the time to parse the at(1) sources ;) Then it would be as simple as making the command-line scheduling utility write the job into the at-next-boot utility spool dir instead of the regular at(1) spool dir; or maybe the at-next-boot utility could just look through the regular at(1) spool dir for some specially-marked files that at(1) would ignore.. I would be willing to do this, if no one else volunteers. G'luck, Peter -- This would easier understand fewer had omitted. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC FFS dirpref code?
On Sun, Jul 22, 2001 at 12:01:46PM -0700, Matt Dillon wrote: : : ::could anyone think about MFC FFS dirpref code? ::is it still not enough stable in CURRENT? ::I heard OpenBSD 2.9 has it already. : :Kirk aksed me to do in a month or two ago. It's been on my TODO list :but I haven't had time to do it yet. It's still on my TODO list. ARRRG Kirk ASKED me to do IT a month or two ago. Sorry, that's worse then my typical typing, I was thinking about something else at the time and left my fingers on auto. Well, this particular one was easy to spot - if Kirk had indeed axed you, you wouldn't be there replying to this email :) (Or would you.. visions of AI's, simulations and plain old poltergeists..) G'luck, Peter -- Thit sentence is not self-referential because thit is not a word. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: KLD parameters
Actually, it is implemented - to some extent - in -current via the hints mechanism. There is still some more work to be done, though :) G'luck, Peter -- yields falsehood, when appended to its quotation. yields falsehood, when appended to its quotation. On Thu, Jul 19, 2001 at 03:02:40AM -0400, Andrew R. Reiter wrote: This was discussed before... I think if you want it, implement it. :-/ andrew On Thu, 19 Jul 2001, Eugene L. Vorokov wrote: Hello, it seems that I can't pass any parameters to a KLD module when I load it (i.e., some command line). Am I missing something, or if not, why is it like that, on purpose or just no one was willing to implement that ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Weird stdarg.h problem in 4.3-STABLE
On Wed, Jul 18, 2001 at 07:34:08PM +0200, Sheldon Hearn wrote:
Hi folks,
I'm busy developing a libdaemon implementation and have come unstuck on
a weird problem with functions using variable argument lists in FreeBSD
4.3-STABLE.
What I really want is a static inline void function declared in a header
file and included in various source files, looking something like this:
static inline void
xdaemonwarn(char *fmt, ...)
{
va_list ap;
va_start(ap, fmt);
if (!daemon_quiet)
warn(fmt, ap);
va_end(ap);
return;
}
Err. Snipped the rest, since this code snippet contains
an important mistake.
warn() does not take a va_list as an argument.
Try using vwarn(fmt, ap) instead, and your function looks fine.
G'luck,
Peter
--
I've heard that this sentence is a rumor.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Weird stdarg.h problem in 4.3-STABLE
On Wed, Jul 18, 2001 at 08:47:15PM +0300, Peter Pentchev wrote:
On Wed, Jul 18, 2001 at 07:34:08PM +0200, Sheldon Hearn wrote:
Hi folks,
I'm busy developing a libdaemon implementation and have come unstuck on
a weird problem with functions using variable argument lists in FreeBSD
4.3-STABLE.
What I really want is a static inline void function declared in a header
file and included in various source files, looking something like this:
static inline void
xdaemonwarn(char *fmt, ...)
{
va_list ap;
va_start(ap, fmt);
if (!daemon_quiet)
warn(fmt, ap);
va_end(ap);
return;
}
Err. Snipped the rest, since this code snippet contains
an important mistake.
warn() does not take a va_list as an argument.
Try using vwarn(fmt, ap) instead, and your function looks fine.
To elaborate a bit: a va_list is a pointer to a memory area where
the arguments are stored; a '...' means that this actual memory
area lies on the stack. Thus, a va_list is a *pointer* to what
warn() expects, and it is exactly this pointer that vwarn() needs.
G'luck,
Peter
--
I am jealous of the first word in this sentence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Cron program core dumped (signal 11)
On Mon, Jul 16, 2001 at 06:00:01PM +0200, Chojin wrote: cd /usr/src/usr.sbin/cron make cleandir depend make CFLAGS=-ggdb -g3 STRIP= all install ..then run '/usr/sbin/cron' from the command line, and see if it leaves a coredump in the current directory. If it does, then do the following: gdb /usr/sbin/cron /path/to/cron.core (at the gdb prompt) bt info local up info local up info local [repeat until highest level] Hm. Now that I kinda tested this, cron doesn't seem to leave a corefile. Well, still.. this message was redirected to -stable in the hope that somebody there would know better how to help :\ G'luck, Peter -- This sentence claims to be an Epimenides paradox, but it is lying. Okay, I followed your instructions: (I purposefully redirected this to -stable.. since you don't want to acknowledge it is a -stable issue, staying on -hackers this time..) The stack trace you posted seems to imply that cron is dying while processing rico's crontab, and is dying at such a point in the code that would indicate that rico's account has expired. Is that the case? If so, then the easiest thing for you to do would be to remove rico's crontab (crontab -u rico -l rico.cron.save crontab -u rico -r) until rico's account is reactivated or totally removed. 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-hackers in the body of the message
Re: mail failed, returning to sender
On Sun, Jul 15, 2001 at 06:36:52AM +0300, Giorgos Keramidas wrote: From: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: mail failed, returning to sender Date: Sun, Jul 15, 2001 at 04:10:41AM +0200 freebsd-hackers-digest Saturday, July 14 2001 Volume 05 : Number 180 Doesn't mail that failed to deliver get this poor guy unsubscribed automagically, if it happens more than a few times? It probably does, if it is bounced to the right address :( I have a strong suspicion that the MTA at provi.de does not really honor the Return-Path, that should point to owner-listname, and sends the bounce to listname instead.. this way, the Majordomo bounce handlers never realize that this is a bounce. G'luck, Peter -- I had to translate this sentence into English because I could not read the original Sanskrit. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fw: help me!!!!
On Thu, Jul 12, 2001 at 08:28:31PM +0530, srinivasarao wrote: -Original Message- From: srinivasarao [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thursday, July 12, 2001 8:14 PM Subject: help me hi all, i want to compile the seperate folder instead of compiling the kernel . Is there any possibility like that..? Suppose i had made changes in the file ie_if.c in /usr/src/sys/dev/ie, so instead of compiling kernel, i want to compile only the folder ie. is it possible? if possible then how can i proceed, and what are the steps to be taken care? Please help me in this regard. If by 'folder' you mean a 'directory', and in particular, a directory living under src/sys/modules/, then you are actually trying to compile a module. You do it by: cd /usr/src/sys/modules/blah make clean depend make all install clean However, there is no 'ie' or 'if_ie' module for the 'ie' interface; this means that you are stuck with recompiling the whole kernel. G'luck, Peter -- Thit sentence is not self-referential because thit is not a word. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Installworld failure!
On Fri, Jul 06, 2001 at 09:13:08PM +, John Toon wrote: Hi, Ack, make installworld failed! The Makefile seems broken: Dionysus# make installworld mkdir -p /tmp/install.281 for prog in [ awk cat chflags chmod chown date echo egrep find grep install ln make makewhatis mtree mv perl rm sed sh sysctl test true uname wc zic; do cp `which $prog` /tmp/install.281; done usage: cp [-R [-H | -L | -P]] [-f | -i] [-pv] src target cp [-R [-H | -L | -P]] [-f | -i] [-pv] src1 ... srcN directory *** Error code 64 Stop in /usr/src. *** Error code 1 Stop in /usr/src. The cp command is being called incorrectly... Anyone got any suggestions? A very stupid question: you *did* to a 'make buildworld' first, right? :) G'luck, Peter -- What would this sentence be like if it weren't self-referential? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Installworld failure!
On Mon, Jul 09, 2001 at 02:58:00PM +0300, Peter Pentchev wrote: On Fri, Jul 06, 2001 at 09:13:08PM +, John Toon wrote: Hi, Ack, make installworld failed! The Makefile seems broken: Dionysus# make installworld mkdir -p /tmp/install.281 for prog in [ awk cat chflags chmod chown date echo egrep find grep install ln make makewhatis mtree mv perl rm sed sh sysctl test true uname wc zic; do cp `which $prog` /tmp/install.281; done usage: cp [-R [-H | -L | -P]] [-f | -i] [-pv] src target cp [-R [-H | -L | -P]] [-f | -i] [-pv] src1 ... srcN directory *** Error code 64 Stop in /usr/src. *** Error code 1 Stop in /usr/src. The cp command is being called incorrectly... Anyone got any suggestions? A very stupid question: you *did* to a 'make buildworld' first, right? :) That should have been you did *do* a 'make buildworld' first.. G'luck, Peter -- You have, of course, just begun reading the sentence that you have just finished reading. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Mall now BSDCentral
On Fri, Jul 06, 2001 at 12:38:33PM +0200, Noses wrote: In [EMAIL PROTECTED] [EMAIL PROTECTED] (Jordan Hubbard) wrote: Yeesh, you'd think I'd announced my funeral by how some people have taken this whole Apple thing. :-) If so - where will the funeral be held and will there be Jordan soup for sharing and grokking (although I'd prefer some other people to donate some food)? I sincerely hope they do, though I obviously can't do much from the WRS side of things now (not that I necessarily could before either). If they consider FreeBSD to be a product they accquired why should they turn the trade mark over? I don't think that they think that they acquired FreeBSD. At least, their announcements seemed to specifically deny any such fears. G'luck, Peter -- This sentence is false. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: LIST_NEXT()
On Fri, Jul 06, 2001 at 09:48:26AM -0400, Evan Sarmiento wrote:
Hello,
I'm writing a kernel module, and it involves traversing the proc list searching for
the right structure,
however, when I use SLIST_NEXT(p, p_list) in the program, I get a warning when I
compile it:
warning: statement with mo effect
What am I doing wrong? I've read the manpages on queue and looked at the proc
structure.
Here's the code:
int
prfw_setflags(p, uap)
struct proc *p;
struct prfw_setflags_args *uap;
{
...
if (uap-id) {
while (uap-id != p-p_pid)
LIST_NEXT(p, p_list);
}
Well, first, you're using LIST_NEXT(), not SLIST_NEXT() :)
Second, none of the *_NEXT() queue.h macros modify their parameters;
they just return a pointer to the next element. So, just try:
p = LIST_NEXT(p, p_list);
..and you'll be just fine.
G'luck,
Peter
--
If I were you, who would be reading this sentence?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Proper use of select() parameter nfds?
On Fri, Jul 06, 2001 at 09:58:00AM -0400, Matthew Hagerty wrote: Greetings, I am going over the use of select() for a server I'm writing and I *thought* I understood the man page's description for the use of the first parameter, nfds. From MAN: The first nfds descriptors are checked in each set; i.e., the descriptors from 0 through nfds-1 in the descriptor sets are examined. I take this to mean that each descriptor set contains n descriptors and I am interested in examining the first nfds descriptors referenced in my sets. I also understood it to mean that nfds has absolutely nothing to do with the actual *value* of a descriptor, i.e. the value returned by fopen(), socket(), etc.. Is this correct thinking? What got me second-guessing myself was a use of select() that seems to indicate that you have to make sure nfds is larger than the value of the largest descriptor you want checked. Here is the select() from the questionable code (I can provide the whole function if necessary, it's not very big): if (select(conn-sock + 1, input_mask, output_mask, except_mask, (struct timeval *) NULL) 0) Actually, this is the correct use. nfds should be larger than the value of the largest fd in the set, no matter how many fd's there are. Is this improper use? conn-sock is set like this: /* Open a socket */ if ((conn-sock = socket(family, SOCK_STREAM, 0)) 0) Any clarification on how nfds should be set would be greatly appreciated. Maybe it would help if you thought of an fd set as of a bit array, with a '1' bit for each fd in the set, and a '0' for each fd not in the set. The nfds argument tells select(2) how far into the bit array to check for set bits. If you want to check fd's 0, 1 and 5, then nfds should be at least 6. For more information, I would suggest reading W. Richard Stevens' book Unix Network Programming, vol. 1. G'luck, Peter -- You have, of course, just begun reading the sentence that you have just finished reading. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Quick question on kgdb
Possibly dumb question: OK, you specified makeoptions DEBUG=-g in your kernel config file. Did you also run config(8) with the -g option? G'luck, Peter -- The rest of this sentence is written in Thailand, on On Sat, Jun 30, 2001 at 10:59:35PM -0400, [EMAIL PROTECTED] wrote: Both the kernel and kernel.debug files are of exactly the same size - about 3.3 Megs . This is inspite of having the DEBUG=-g option being set in the MYKERNEL directory. Any other clues, why this could be happening. I also tried the other procedure of using 'make depend' etc as outlined in the doc, but that produced the same results. What else could I be missing? -AG David Malone [EMAIL PROTECTED] wrote: On Sat, Jun 30, 2001 at 12:14:51AM -0400, [EMAIL PROTECTED] wrote: when I load up the installed kernel in / with 'gdb -k kernel' .. it says debugging symbols not found The kernel which is installed is stripped of debugging symbols - you sound find a kernel.debug with symbols in teh compile directory. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: autoconf undefined macros
On Mon, Jul 02, 2001 at 08:30:35AM +0200, Nicolas Souchu wrote: Hi, The 2.13_1 complains about this: ladoga:/usr/home/admin/nsouch/ggi-core/libgiiautoconf configure.in:157: warning: AC_TRY_RUN called without default to allow cross compiling autoconf: Undefined macros: configure.in:247:AC_CHECK_WINFUNCS(gettimeofday strdup nanosleep usleep _exit \ configure.in:39:AC_LIBTOOL_DLOPEN configure.in:40:AC_LIBTOOL_WIN32_DLL ladoga:/usr/home/admin/nsouch/ggi-core/libgii And autoconf-2.50 gives me: ladoga:/home/admin/nsouch/ggi-core/libgiiautoconf configure.in:8: error: possibly undefined macro: AM_INIT_AUTOMAKE configure.in:10: error: possibly undefined macro: AM_MAINTAINER_MODE configure.in:11: error: possibly undefined macro: AM_DISABLE_STATIC configure.in:39: error: possibly undefined macro: AC_LIBTOOL_DLOPEN configure.in:40: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL configure.in:41: error: possibly undefined macro: AM_PROG_LIBTOOL configure.in:247: error: possibly undefined macro: AC_CHECK_WINFUNCS configure.in:397: error: possibly undefined macro: AM_CONDITIONAL configure.in:665: error: possibly undefined macro: AM_CONFIG_HEADER Do you have any clue? Have you tried this with a newer automake, too? AFAIK, the newer versions of autoconf and automake are totally in-backwards-compatible :( G'luck, Peter -- because I didn't think of a good beginning of it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: autoconf undefined macros
On Mon, Jul 02, 2001 at 01:58:08PM +0200, Nicolas Souchu wrote: On Mon, Jul 02, 2001 at 11:21:11AM +0300, Peter Pentchev wrote: On Mon, Jul 02, 2001 at 08:30:35AM +0200, Nicolas Souchu wrote: Hi, The 2.13_1 complains about this: ladoga:/usr/home/admin/nsouch/ggi-core/libgiiautoconf configure.in:157: warning: AC_TRY_RUN called without default to allow cross compiling autoconf: Undefined macros: configure.in:247:AC_CHECK_WINFUNCS(gettimeofday strdup nanosleep usleep _exit \ configure.in:39:AC_LIBTOOL_DLOPEN configure.in:40:AC_LIBTOOL_WIN32_DLL ladoga:/usr/home/admin/nsouch/ggi-core/libgii And autoconf-2.50 gives me: ladoga:/home/admin/nsouch/ggi-core/libgiiautoconf configure.in:8: error: possibly undefined macro: AM_INIT_AUTOMAKE configure.in:10: error: possibly undefined macro: AM_MAINTAINER_MODE configure.in:11: error: possibly undefined macro: AM_DISABLE_STATIC configure.in:39: error: possibly undefined macro: AC_LIBTOOL_DLOPEN configure.in:40: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL configure.in:41: error: possibly undefined macro: AM_PROG_LIBTOOL configure.in:247: error: possibly undefined macro: AC_CHECK_WINFUNCS configure.in:397: error: possibly undefined macro: AM_CONDITIONAL configure.in:665: error: possibly undefined macro: AM_CONFIG_HEADER Do you have any clue? Have you tried this with a newer automake, too? AFAIK, the newer Newer than 2.50? I meant the automake version, not autoconf. versions of autoconf and automake are totally in-backwards-compatible :( So the 2.13_1 version seems to be the closest to my configure.in file. Then, could it be some missing macros in the FreeBSD installation? If the configure.in and Makefile.am files (and similar) are created for autoconf-2.50 *and* automake 1.4 (e.g. 1.4d), they won't work with any combination of autoconf = 2.50 and automake 1.4. Trust me, I've tried. The only thing I *haven't* tried so far is actually try to update my automake to 1.4d or similar. G'luck, Peter -- If there were no counterfactuals, this sentence would not have been paradoxical. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Flight of the rat, living wreck.....
No real knowledge of the ipfw code or the motives behind it here, but just a comment.. On Sat, Jun 30, 2001 at 06:51:33PM +0800, Igor Podlesny wrote: [snip] // so here we start looking through the queue ia != NULL // sanity (I'd have written just (ia)) Yep, just (ia) would have worked, but style(9) mandates (ia != NULL), which is much easier to understand and follow at a glance (clearly showing that ia is not a flag, but a pointer). G'luck, Peter -- I am the meaning of this sentence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
create executable images from core files?
Hi, While reading the perlrun(1) manpage today, I stumbled upon a reference to an undump utility that could convert a core file into an executable image (arguably much larger than the actual executable text, because it would have to include the data portions, too). Is there anyhing similar available for FreeBSD/ELF? Yes, I've read the next sentence that says that the Perl-to-C compiler is much more effective, but this reference to undump just piqued my curiosity, and I just had to ask :) G'luck, Peter -- If I had finished this sentence, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
On Fri, Jun 29, 2001 at 10:55:39AM -0400, [EMAIL PROTECTED] wrote: In a message dated 6/28/01 11:16:31 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: Really? Have you even looked at the net4501 board which was mentioned? It's a single-board computer constructed for some specific communication applications, with no VGA or keyboard support, or spinning fans, and is pretty inexpensive and in a very small form factor. Why do I want to replace this with a new motherboard? Because my motherboard is 20 times faster, has VGA support,doesnt require an add-on board to do fast encryption and costs about the same as yours. Thats why. Again, you are only considering your personal case. If crypto should be needed on an embedded appliance, I don't think they would need a lightning-fast processor and VGA support, when crypto is all they want. G'luck, Peter -- yields falsehood, when appended to its quotation. yields falsehood, when appended to its quotation. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
On Fri, Jun 29, 2001 at 03:19:47PM +, E.B. Dreger wrote: The threads scheduler is in user space. It converts a blobking call into a non-blocking call plus a context switch. THus blocking _IS_ a problem. Bad wording on my part again; perhaps a problem that I [think that] I have handled is better. I'm use nb calls if possible; else I have a long-running worker thread. I hope you understand that when the worker thread blocks, it's the process that blocks, and none of the other threads can run until the end of the syscall. After my recent question regarding AIO, it looks like it's time to bite the bullet and use that as well. G'luck, Peter -- If this sentence were in Chinese, it would say something else. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: does data overflow in pipes
It is also possible that it would only write as much as it can, and return the amount written, leaving it to you to write the rest later. (Uhm.. you do check the return values from write(2), right? :) The relevant source is in src/sys/kern/sys_pipe.c, namely the pipe_write() function. From a quick look, it would seem that writes behave exactly the way I thought - only writing as much as there is space left in the pipe buffer. G'luck, Peter -- I am the meaning of this sentence. On Wed, Jun 27, 2001 at 10:45:21PM -0400, Zhihui Zhang wrote: I guess the kernel will block the process trying to write more data than that can be accommodated. Or if you are using non-blocking I/O, it will return an error. -Zhihui On Wed, 27 Jun 2001, Manas Bhatt wrote: hi all, pipes uses only direct blocks to store data. so depending on the blocksize , a total data of 10*blocksize can be written in one go but what happens if a writer process tries to write more 10*blocksize of data in one go. Does the kernel overwrites the data in pipe or not ? if yes, why? if not, then how does it allow the writer to write more 10*blocksize of data? if someone can direct me to implementation (source files), it would be great. thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: swapping bytes, fpos_t
On Tue, Jun 26, 2001 at 06:06:59AM -0700, Marc van Woerkom wrote: Oh yes, and I used fpos_t in all parts of libdvdread, that were used for seeking. Is this ugly, should better use the uint64 type burried deep with the machine dependent headers? What is good coding practice here? For seeking, use off_t. It is a 64-bit signed integer. If you need real 64-bit offsets (unsigned), then you might use uoff_t; but off_t should be enough, and it *is* the standard type for seek offsets. G'luck, Peter -- Thit sentence is not self-referential because thit is not a word. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: include directive in config(8) (was: Two Junior Kernel Hacker tasks..)
On Mon, Jun 25, 2001 at 08:27:35AM +0300, Valentin Nechayev wrote: Mon, Jun 25, 2001 at 00:05:36, clefevre-lists (Cyrille Lefevre) wrote about Re: include directive in config(8) (was: Two Junior Kernel Hacker tasks..): how about undef options XXX and undef device XXX, etc. ? s/undef/no/ I like Cisco style ;))) This sounds nice. G'luck, Peter -- This inert sentence is my body, but my soul is alive, dancing in the sparks of your brain. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On Sat, Jun 23, 2001 at 10:44:51PM -0700, John Baldwin wrote: On 23-Jun-01 Peter Pentchev wrote: On Sat, Jun 23, 2001 at 12:23:35PM -0700, Terry Lambert wrote: make buildkernel is rather easy way to work it around: in any case object tree is machine-dependent, and one yet another directory does not destroy anything. ;| The make buildkernel approach sucks for incremental builds, since you are unable to avoid the config run each time, and a lot of unnecessary stuff gets compiled again because of opt_*.h files whose contents have not changed (even if you defeat the clean of the compile directory). About the release process, you are right, it is a bit harder to restart without some tweaks, but the buildkernel target is about as restartable as it can be. (I really don't think anyone would ever advocate skipping the config(8) or the 'make depend' stage..) Actually, make depend takes a relatively long time, and when I'm hacking on a kernel, I don't want to wait 15 minutes to build a kernel after changing one file. I compile kernels w/o config or make depend a lot. OK, so if you're really really sure your changes do not affect the dependency graph, use -DNOKERNELDEPEND :) G'luck, Peter -- This sentence contains exactly threee erors. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: how to invalidate scsi connection to driver module
On Fri, Jun 22, 2001 at 06:39:09PM +0100, j mckitrick wrote: Here is the code for a scsi removable media drive. If this is to become a module, the cam/scsi attachment must be removed. I have tried calling cam_sim_free() and xpt_bus_deregister() but when the module is reloaded, the cam system assigns the next higher minor device number, and then crashes when accessed. Any ideas here how to reset cam to a state where it knows nothing about the device? I might be dead wrong here, but I think the different *types* of SCSI devices are compiled statically in the kernel, and not intended to be unloaded. See the kernel options 'da', 'cd', 'pass' et al. What I mean is that what you are trying to do might not be even possible, at least with the current state of the CAM code. And of course, I may have completely misunderstood what you are trying to do :) G'luck, Peter -- If wishes were fishes, the antecedent of this conditional would be true. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: how to invalidate scsi connection to driver module
Isn't this what 'camcontrol rescan' is for? G'luck, Peter -- This sentence contains exactly threee erors. On Sat, Jun 23, 2001 at 10:38:53AM -0700, Matthew Jacob wrote: But the unit numbers can and do recycle. On Sat, 23 Jun 2001, Peter Pentchev wrote: On Fri, Jun 22, 2001 at 06:39:09PM +0100, j mckitrick wrote: Here is the code for a scsi removable media drive. If this is to become a module, the cam/scsi attachment must be removed. I have tried calling cam_sim_free() and xpt_bus_deregister() but when the module is reloaded, the cam system assigns the next higher minor device number, and then crashes when accessed. Any ideas here how to reset cam to a state where it knows nothing about the device? I might be dead wrong here, but I think the different *types* of SCSI devices are compiled statically in the kernel, and not intended to be unloaded. See the kernel options 'da', 'cd', 'pass' et al. What I mean is that what you are trying to do might not be even possible, at least with the current state of the CAM code. And of course, I may have completely misunderstood what you are trying to do :) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: how to invalidate scsi connection to driver module
On Sat, Jun 23, 2001 at 08:09:46PM +0100, j mckitrick wrote: On Sat, Jun 23, 2001 at 10:38:53AM -0700, Matthew Jacob wrote: | | But the unit numbers can and do recycle. So the question is then, how can i get it to do that? If 'camcontrol rescan' would do what you want, then look at how it is implemented in kernel space. I'm not too comfortable around kernel code, but 'rescan' invokes the CAMIOCOMMAND ioctl with an argument of XPT_SCAN_BUS, and the xpt device ioctl's in src/sys/cam/cam_xpt.c around line 978 (on -stable) seem to call some cam_*() internal functions that you could probably call yourself. Hope this help some.. G'luck, Peter -- I had to translate this sentence into English because I could not read the original Sanskrit. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On Sat, Jun 23, 2001 at 12:23:35PM -0700, Terry Lambert wrote: make buildkernel is rather easy way to work it around: in any case object tree is machine-dependent, and one yet another directory does not destroy anything. ;| The make buildkernel approach sucks for incremental builds, since you are unable to avoid the config run each time, and a lot of unnecessary stuff gets compiled again because of opt_*.h files whose contents have not changed (even if you defeat the clean of the compile directory). Terry, this is simply not true. Even in -stable, config(8) is smart enough to try reading the opt_*.h files, and not change them if they already contain the values it is about to write there. See for yourself: [root@ringworld:v1 /usr/src]# LANG=C ls -lt /usr/obj/usr/src/sys/RINGWORLD/opt_*.h | head -2 -rw-r--r-- 1 root wheel0 Jun 11 23:35 /usr/obj/usr/src/sys/RINGWORLD/opt_aac.h -rw-r--r-- 1 root wheel0 Jun 11 23:35 /usr/obj/usr/src/sys/RINGWORLD/opt_wavelan.h [root@ringworld:v1 /usr/src]# As you can see, the two most recent files date back to June 11th... [root@ringworld:v1 /usr/src]# LANG=C ls -lt /usr/obj/usr/src/sys/RINGWORLD | head -3 total 6187 -rw-r--r-- 1 root wheel 424510 Jun 23 22:51 .depend -rwxr-xr-x 1 root wheel 1963795 Jun 23 14:34 kernel [root@ringworld:v1 /usr/src]# ..the kernel was rebuilt today at 14:34, and the .depend file was regenerated by a 'make -DNOCLEAN buildkernel' about two minutes ago. No opt*.h files were changed, NO recompilation was done, since everything was completely up-to-date. About the release process, you are right, it is a bit harder to restart without some tweaks, but the buildkernel target is about as restartable as it can be. (I really don't think anyone would ever advocate skipping the config(8) or the 'make depend' stage..) G'luck, Peter -- When you are not looking at it, this sentence is in Spanish. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Two Junior Kernel Hacker tasks..
On Sat, Jun 23, 2001 at 02:03:53PM -0700, Terry Lambert wrote: Peter Pentchev wrote: Terry, this is simply not true. Even in -stable, config(8) is smart enough to try reading the opt_*.h files, and not change them if they already contain the values it is about to write there. Rerunning config and make depend always result in more things being recompiled for me, than just me typing make. Running 'make buildkernel' results in nothing at all recompiled for me (please read the whole of my message this time). The buildkernel target also can not handle all of the intricacies of all the parameters that you might want to pass to config: things are lost. If it's just parameters you want to pass, then use the CONFIG_ARGS make env variable. It's not a reasonable workaround to the problem under discussion (building multiple kernels for multiple architectures using one tree). For multiple architectures, no, it is not - but that was the whole point of half this thread, wasn't it? Making the kernel build directories arch-specific.. Example: All my PPC based NetBSD systems run different kernel configurations, specific to the machine (not processor) architecture. But everything other than the kernel and modules should be shared, since all the systems kernels present the same ABI to user space. Rebuilding everything is not a reasonable option. So mount your /usr/obj accordingly - NFS mount of the whole, a local fs (or maybe even a nullfs, but I won't go into that) mount of the kernel-specific subdirs. Then, use buildkernel. [root@ringworld:v1 /usr/src]# LANG=C ls -lt /usr/obj/usr/src/sys/RINGWORLD/opt_*.h | head -2 -rw-r--r-- 1 root wheel0 Jun 11 23:35 /usr/obj/usr/src/sys/RINGWORLD/opt_aac.h -rw-r--r-- 1 root wheel0 Jun 11 23:35 /usr/obj/usr/src/sys/RINGWORLD/opt_wavelan.h [root@ringworld:v1 /usr/src]# As you can see, the two most recent files date back to June 11th... Next time, include the other things like param.c and so on, created by config. I want to avoid _all_ unnecessary rebuilds. Uh.. excuse me? Did you read two lines further, where I pasted an ls of the *same* directory, and the two *most recent* files? Only the .depend file had a modification time two minutes ago, the kernel itself was the next file in the list, and it had a mtime of several hours earlier. Not param.c, not vers.c, nothing had beed changed by the buildkernel target. (Technically, the vers.c rebuild is unnecessary, too, since nothing is supposed to have changes, so vers.c should not have been rewritten -- but that's another discussion... 8-)). Look again. It was not rewritten. G'luck, Peter -- If I had finished this sentence, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: whois(1) patch for review
On Thu, Jun 21, 2001 at 04:08:21PM +0300, Alexey Zelkin wrote: hi, I have made few modifications to whois(1) to shut up BDECFLAGS warnings, cleanup code, and add new features. [snip] Resume: with this patch included to add new country's whois server we'll need to add only one string to text file, not to modify whois(1) code as it has been done by Andrey for '-R' and as some pending PR's proposed to do. PS: I also removed -R switch for whois(1) which was used to point to Russian whois server, since it is replaced with -c ru PPS: It's tested on STABLE, but I don't think that there can be problems with -current. PPPS: Patch is dirty threfore any ideas on its cleanup are welcome. Also additional idea on improving whois(1) flexibility are welcome! I hope to get some free time on this weekend and commit it if nobody has strong objections. http://phantom.cris.net/~phantom/whois_patch.tgz Wow. I think there's been a GREAT deal of duplication of effort over whois(1).. Have you looked at Mike Barcroft's patches, posted both as a PR and as a longish thread on -audit a couple of days ago, or at Joachim Strombergson's patches, posted as a longish thread on -audit a month or so ago? My understanding is that Mike Barcroft's patches remove the warnings, and Joachim Strombergson was working on the server list thing :) G'luck, Peter -- This sentence would be seven words long if it were six words shorter. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article Network performance by OS
On Mon, Jun 18, 2001 at 12:34:53PM +0200, Karsten W. Rohrbach wrote:
Dag-Erling Smorgrav([EMAIL PROTECTED])@2001.06.17 07:48:27 +:
Second, we tried turning write caching on ATA drives off by default,
and boy were you (the user community) pissed. Yes, turning wc off
shows you just how crappy those non-tagged-queueing 4000 RPM ATA
drives you picked up at Fry's for some pocket change are. So we
turned it back on. If you're not happy with that, put 'hw.ata.wc=0'
in your /boot/loader.conf and they'll be off after the next reboot.
Or get real disks.
that's one for the handbook, eh? imagine:
Q: i got problem {...}, it seems to depend on (ATA|IDE|disk|drive|...)
A: get real hardware, you're running a production system, aren't you?
it would be a nice thing[tm] to have such stuff in the docs.
Can we put your e-mail address below, to direct there all the feedback
from home users with IDE drives? :P
G'luck,
Peter
--
If I were you, who would be reading this sentence?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Query: How to tell if Microsoft is using BSD TCP/IP code?
On Sun, Jun 17, 2001 at 01:16:20PM +0200, Jeroen Massar wrote:
Jordan Hubbard [EMAIL PROTECTED] wrote:
I've had several marketing types approach me recently for details as
to whether or not Microsoft was using the BSD TCP/IP stack and/or user
utilities, and though it's always been common knowledge in the
community that they were, when I set about to prove it I found it to
be less easy than I'd thought. I've strings'd various binaries and
DLLs in my copy of Windows 98 but have yet to find anything resembling
proof. Does anyone out there have any details or discovery techniques
for confirming or disproving this assertion either way? It would be
very useful (for us) from a PR standpoint to know.
I don't know what you are trying to get from all this,
especially the It would be very useful (for us) from a PR standpoint to
know. part.
It all sounds really odd to me but alas a cat does stupid things when it
gets cornered...
I sincerely hope that you BSD guysgals stay far far away from the
microsoft is evil, we can't win it easily so let's bash it to
hell-attitude.
{and that's my opinion, it's a freespeech world so don't start flaming
me all of a sudden)
Your technical arguments are very nice and may turn out to be useful.
However, I can't say I agree with your comments. Jordan did NOT say
that he wanted to prove MS had, like, stolen the BSD networking code;
he merely said he was interested in proving or disproving any degree
of BSD-derivation of the Windows TCP/IP stack.
Saying that Solaris, IRIX, AIX and who-not have great parts of the
OS derived from SysV or BSD code is not really 'bashing' those OS's,
is it? There is still a large amount of their own code, created
with a large amount of work put in; the 'derived' part simply means
that they have given credit to others' work by reusing it.
Thus, if it turns out that Microsoft have really derived their TCP/IP
stack from the BSD one, this would not mean they've stolen the BSD stack
for lack of wits to write their own; it would simply means that they have
decided that the BSD stack was a nice piece of code, and it would not have
been worth it to put in all the effort necessary to rewrite it from
the ground up.
G'luck,
Peter
--
What would this sentence be like if it weren't self-referential?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Fri, Jun 15, 2001 at 02:09:19AM -0700, Terry Lambert wrote: Mike Silbersack wrote: Rather than a tuned configuration, what would be useful is a script that would evaluate a system and give tuning hints. This might be simple for someone familiar with shell scripting or perl. It could do something like: [ ... Eliza program for FreeBSD ... ] Doing this is non-trivial. Many of the things they should have tuned can not be tuned except at compile time. And Mike did not imply this tuning could be done without recompiling. As a matter of fact, one of the suggestions in his example involved the words 'change to X and recompile'. G'luck, Peter -- I've heard that this sentence is a rumor. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Query: How to tell if Microsoft is using BSD TCP/IP code?
With the full knowledge that what I'm saying will probably be of no use, I have a personal friend who is a Microsoft certified developer, with full access to the source code of most Windows versions and other well-known Microsoft apps. He has told me more than once that, yes, the NT TCP/IP stack is somewhat BSD-derived, but from other conversations I gather that he has had to change things on his personal machines (things that never made it, and probably never will, in any MS official distribution), to make it *more* BSD-like. I'll ask him for details, and for any links, but you shouldn't really expect an answer before Monday.. G'luck, Peter -- When you are not looking at it, this sentence is in Spanish. On Fri, Jun 15, 2001 at 02:01:17PM -0700, Jordan Hubbard wrote: Do you have a pointer to what you read? I really need HARD evidence here, not just anecdotal stuff. Thanks! - Jordan From: Steve B. [EMAIL PROTECTED] Subject: Re: Query: How to tell if Microsoft is using BSD TCP/IP code? Date: Fri, 15 Jun 2001 13:59:51 -0700 What I read awhile back was MS licensed from BSDi their TCP/IP stack for use in W2K. Steve B. - Original Message - From: Jordan Hubbard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 15, 2001 1:57 PM Subject: Query: How to tell if Microsoft is using BSD TCP/IP code? I've had several marketing types approach me recently for details as to whether or not Microsoft was using the BSD TCP/IP stack and/or user utilities, and though it's always been common knowledge in the community that they were, when I set about to prove it I found it to be less easy than I'd thought. I've strings'd various binaries and DLLs in my copy of Windows 98 but have yet to find anything resembling proof. Does anyone out there have any details or discovery techniques for confirming or disproving this assertion either way? It would be very useful (for us) from a PR standpoint to know. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: rc, was: Re: Plan to import NetBSD rc system
On Thu, Jun 14, 2001 at 10:49:11AM +0300, Danny Braniss wrote:
I've asked -ports before whether it is suitable to let ports startup scripts
honor /etc/rc.conf{,.local} settings by sourcing /etc/defaults/rc.conf and
then running a source_rc_confs (or whatever is appropriate).
my suggestion:
this is the 'modified' loop for the ${local_startup} in /etc/rc:
case ${local_startup} in
[Nn][Oo] | '')
;;
*)
echo -n 'Local package initialization:'
for dir in ${local_startup}; do
if [ -d ${dir} ]; then
for script in ${dir}/*.sh; do
s=`basename ${script} .sh`
v=`eval echo '$'${s}_enable|dd conv=ucase`
if [ -x ${script} -a ${v} = YES ]; then
(set -T
trap 'exit 1' 2
${script} start)
fi
done
fi
done
echo '.'
;;
esac
you just add: mysql_enable=YeS
OK, and what do I do if I want to manually start/stop the service later,
and it needs variables defined in /etc/rc.conf{,local} ?
G'luck,
Peter
--
This sentence would be seven words long if it were six words shorter.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: rc, was: Re: Plan to import NetBSD rc system
On Thu, Jun 14, 2001 at 08:59:16PM +0200, Karsten W. Rohrbach wrote:
Peter Pentchev([EMAIL PROTECTED])@2001.06.14 20:19:27 +:
OK, and what do I do if I want to manually start/stop the service later,
and it needs variables defined in /etc/rc.conf{,local} ?
if [ x${_RC_CONF} != x1 ]; then . /etc/rc.conf; fi
in the beginning of the local startup script?
if it really requires it, it could plainly source it in the beginning,
or selectively using the above if statement when /etc/defaults/rc.conf
would do _RC_CONF=1; export _RC_CONF
that's not a very good idea, but it would - at least - fix the behaviour
to be the right way. please read on...
Not really; it's a great start, but something like..
if [ -z $_RC_CONF ]; then
. /etc/defaults/rc.conf
if type source_rc_confs | fgrep shell function /dev/null; then
source_rc_confs
else
rc_conf_files=${rc_conf_files-'/etc/rc.conf /etc/rc.conf.local'}
for i in $rc_conf_files; do
if [ -r $i ]; then
. $i
fi
done
fi
_RC_CONF=1 # just in case..
fi
..would do the trick better :)
G'luck,
Peter
--
I am not the subject of this sentence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Re: import NetBSD rc system [summary]
On Thu, Jun 14, 2001 at 12:03:02PM -0700, David O'Brien wrote: On Thu, Jun 14, 2001 at 10:48:49AM -0700, Jordan Hubbard wrote: I think that since we use CVS around here, we should simply import the Some time tonight I will be vendor importing the NetBSD rc system. (no it will not be functional at that time). I am doing this to help the various efforts that are working on this so they can pass round patches vs. entire files. Erm.. Sheldon Hearn has expressed a desire to discuss things with Luke Mewburn in the hope of coming to some mutual agreement as to directions and improvements. Have you discussed this vendor import of the current NetBSD RC system with him? Wouldn't it be better to wait until Luke himself says something about the possible future directions the common RC system might want to take? G'luck, Peter -- What would this sentence be like if it weren't self-referential? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Plan to import NetBSD rc system
On Wed, Jun 13, 2001 at 11:20:03AM +0300, Danny Braniss wrote:
few points to add/concider:
I share the /usr/local among many machines, so /usr/local/etc/rc.d is becoming
'problematic', rc.conf should be involved in the decission to run xxx.sh
start/stop
on other platforms, i've modified rc to run rc.`hostname` if such file exists.
this little trick saved the day many times - i would dump|restore the root
partition onto another host, and reboot.
having to manage many hosts, it's becoming important to centralize some of
the configuration data (Nis/Hesiod based info). I configure amd that is
heavely used here, via hesiod.
having experienced rc since V6, i have seen some nice ideas and 01some
22horrible
99ones, FreeBSD's so far looks the best! true, i haven't seen NetBSD, and i
will
asap.
I've asked -ports before whether it is suitable to let ports startup scripts
honor /etc/rc.conf{,.local} settings by sourcing /etc/defaults/rc.conf and
then running a source_rc_confs (or whatever is appropriate).
This could be a solution to your problem - modify the ports' startup scripts
to honor rc.conf options, then put appropriate enable/disable options
in each machine's /etc/rc.conf or /etc/rc.conf.local.
Attached is an example - a modification of the databases/mysql323-server
port's startup script to honor a couple of mysqld_* variables from
the RC script scheme.
This approach has the disadvantage that the ports' startup scripts will
have to be modified if the base system startup mechanism changes, or
at least when the base system /etc/{defaults}/rc.conf{.local} parsing
mechanism changes.
G'luck,
Peter
--
Do you think anybody has ever had *precisely this thought* before?
Index: ports/databases/mysql323-server/files/mysql-server.sh
===
RCS file: /home/ncvs/ports/databases/mysql323-server/files/mysql-server.sh,v
retrieving revision 1.2
diff -u -r1.2 mysql-server.sh
--- ports/databases/mysql323-server/files/mysql-server.sh 2000/07/05 12:36:21
1.2
+++ ports/databases/mysql323-server/files/mysql-server.sh 2001/03/19 09:25:38
@@ -1,13 +1,39 @@
#!/bin/sh
+. /etc/defaults/rc.conf
+if type source_rc_confs | fgrep 'shell function' /dev/null; then
+ source_rc_confs
+else
+ rc_conf_files=${rc_conf_files-/etc/rc.conf /etc/rc.conf.local}
+ for i in ${rc_conf_files}; do
+ if [ -r $i ]; then
+ . $i
+ fi
+ done
+fi
+
+# The following variables may be overridden in /etc/rc.conf or
+# /etc/rc.conf.local
+
+# The base directory (prefix) for the MySQL installation
+mysqld_prefix=${mysqld_prefix-%%PREFIX%%}
+# The MySQL server executable
+mysqld_program=${mysqld_program-${mysqld_prefix}/bin/safe_mysqld}
+# The MySQL server process, passed to 'killall' to stop the server
+mysqld_process=${mysqld_process-mysqld}
+# The user that the MySQL server runs as
+mysqld_user=${mysqld_user-mysql}
+# Any additional flags for the MySQL server
+mysqld_flags=${mysqld_flags-}
+
case $1 in
start)
- if [ -x %%PREFIX%%/bin/safe_mysqld ]; then
- %%PREFIX%%/bin/safe_mysqld --user=mysql /dev/null echo
-n ' mysqld'
+ if [ -x ${mysqld_program} ]; then
+ ${mysqld_program} --user=${mysqld_user} ${mysqld_flags}
+/dev/null echo -n ' mysqld'
fi
;;
stop)
- /usr/bin/killall mysqld /dev/null 21 echo -n ' mysqld'
+ /usr/bin/killall ${mysqld_process} /dev/null 21 echo -n '
+mysqld'
;;
*)
echo
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: oct() doesn't handle binary strings
On Sat, Jun 09, 2001 at 08:12:48PM -, [EMAIL PROTECTED] wrote:
This is a bug report for perl from [EMAIL PROTECTED],
generated with the help of perlbug 1.26 running under perl 5.00503.
-
[Please enter your report here]
From perlfunc(1):
oct EXPR...
(If EXPR happens to start off with 0x, interprets
it as a hex string. If EXPR starts off with 0b,
it is interpreted as a binary string.)
But the binary string conversion doesn't seem to work:
natto% perl -e 'print oct(0b11000110).\n'
0
This is otherwise a valid binary string:
natto% perl -e 'print unpack('C', (pack(B8, 11000110))).\n'
198
The hex string conversion function does work:
natto% perl -e 'print oct(0xC6).\n'
198
The following comments pertain to the version of Perl used in FreeBSD,
since this was cited as a FreeBSD 4.0 problem.
This is still true for Perl 5.005_03 in -stable, but it seems to have
been fixed in Perl 5.6.0 in -current. I believe this will be fixed
when Perl 5.6 is MFC'd (btw, FreeBSD developers, FreeBSD Perl gurus,
when/if shall Perl 5.6 be MFC'd? :)
Thus, I believe this is not (anymore) a Perl problem per se, since it
is fixed in the newer versions.
G'luck,
Peter
--
If I had finished this sentence,
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: free() and const warnings
On Thu, Jun 07, 2001 at 10:20:51AM -0700, John Baldwin wrote:
On 07-Jun-01 Peter Pentchev wrote:
On Thu, Jun 07, 2001 at 07:07:22PM +0300, Peter Pentchev wrote:
Hi,
Is free((void *) (size_t) ptr) the only way to free a const whatever *ptr
with WARNS=2? (or more specifically, with -Wcast-qual)
Uhm. OK. So size_t may not be enough to hold a pointer. What is it then -
caddr_t?
uintptr_t for data pointers. In theory I think code pointers may not fit in a
uintptr_t.
free((void *)(uintptr_t)ptr) should work.
Of course, this begs the question of why you are free'ing a const. :)
OK, here's a scenario:
struct validation_fun {
const char *name;
valfun *fun;
int dyn;
};
This is a structure for a set of validation functions, referenced by
name from another type of object. There are some predefined functions,
present in the code at compile-time, and hardcoded in an array, with
names given as strings. Thus, the 'const'.
However, some of the functions may be defined at runtime, with both
name and code sent by a server. In that case, the name is a dynamically
allocated char *, which needs to be freed upon cleanup. So I have:
[cleanup function]
...
if (val-dyn)
free(val-name);
Any suggestions on how to improve the design to avoid this, if possible,
would be greatly welcome.
G'luck,
Peter
--
I am the meaning of this sentence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: problem with systm.h trying to call resettodr()
On Fri, Jun 08, 2001 at 12:47:31PM +0100, Rasputin wrote:
I'm playing with resettodr(9), to set the BIOS clock from the system time..
When I try to compile the following snippet,
[rasputin@dogma rasputin]$ cat b0rken.c
#include sys/time.h
#include sys/types.h
#include sys/systm.h
int main(void){
resettodr();
return(0);
}
I get warning about syntax errors in systm.h:
[rasputin@dogma rasputin]$ gcc b0rken.c
In file included from b0rken.c:3:
/usr/include/sys/systm.h:333: syntax error before `int'
/usr/include/sys/systm.h:334: syntax error before `int'
/usr/include/sys/systm.h:335: syntax error before `('
(System is STABLE/RELENG_4 freshly cvsupped a few days ago, although
/usr/src/sys/sys/systm.h doesn't seem to have changed in STABLE
for four months.
Any ideas? I know I'm not exactly '3l337' but I'd say that header file
was screwed. Or am I missing some wierd ass compiler option?
As others pointed out, resettodr(9) is a kernel-space function.
Section 9 of the manual is for those - see the intro(9) manual page
with man 9 intro (just man intro would probably show you intro(1)).
G'luck,
Peter
--
If I had finished this sentence,
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: free() and const warnings
On Fri, Jun 08, 2001 at 06:55:50AM -0400, Thomas David Rivers wrote:
Peter Pentchev [EMAIL PROTECTED] wrote:
On Thu, Jun 07, 2001 at 10:20:51AM -0700, John Baldwin wrote:
On 07-Jun-01 Peter Pentchev wrote:
On Thu, Jun 07, 2001 at 07:07:22PM +0300, Peter Pentchev wrote:
Hi,
Is free((void *) (size_t) ptr) the only way to free a const whatever *ptr
with WARNS=2? (or more specifically, with -Wcast-qual)
Uhm. OK. So size_t may not be enough to hold a pointer. What is it then -
caddr_t?
uintptr_t for data pointers. In theory I think code pointers may not fit in a
uintptr_t.
free((void *)(uintptr_t)ptr) should work.
Of course, this begs the question of why you are free'ing a const. :)
OK, here's a scenario:
struct validation_fun {
const char *name;
valfun *fun;
int dyn;
};
This is a structure for a set of validation functions, referenced by
name from another type of object. There are some predefined functions,
present in the code at compile-time, and hardcoded in an array, with
names given as strings. Thus, the 'const'.
However, some of the functions may be defined at runtime, with both
name and code sent by a server. In that case, the name is a dynamically
allocated char *, which needs to be freed upon cleanup. So I have:
[cleanup function]
...
if (val-dyn)
free(val-name);
Any suggestions on how to improve the design to avoid this, if possible,
would be greatly welcome.
G'luck,
Peter
Since some strings are non-constant (the are allocated) - I believe
the `const' qualifier in the structure declaration is incorrect.
What happens if you simply don't have it in the structure declaration?
GCC complains when I try to initialize the structure with something like:
struct validation_fun val_init[] = {
{init,valfun_init,0}
};
This can be avoided by:
struct validation_fun val_init[] = {
{(char *) (uintptr_t) init, valfun_init,0}
};
..but as a matter of fact, static, pre-initialized valfun structs are
the rule rather than the exception in this program, so having this
syntax for all of them seems.. well.. ugly :)
G'luck,
Peter
--
You have, of course, just begun reading the sentence that you have just finished
reading.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: problem with systm.h trying to call resettodr()
On Fri, Jun 08, 2001 at 01:49:12PM +0100, Rasputin wrote: * Peter Pentchev [EMAIL PROTECTED] [010608 13:35]: On Fri, Jun 08, 2001 at 12:47:31PM +0100, Rasputin wrote: I'm playing with resettodr(9), to set the BIOS clock from the system time.. As others pointed out, resettodr(9) is a kernel-space function. Section 9 of the manual is for those - see the intro(9) manual page with man 9 intro (just man intro would probably show you intro(1)). Thanks, I'd already read intro(9), but it doesn't explain how to *use* kernel-space functions. You can only use kernel-space functions in kernel code, that is, writing a kernel module, or writing a piece of code that is to be compiled along with the rest in src/sys. If you're doing that, look at some kernel source files to see which header files need to be included. If you're not doing that, you cannot use the functions documented in section 9. G'luck, Peter -- This sentence claims to be an Epimenides paradox, but it is lying. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: free() and const warnings
On Fri, Jun 08, 2001 at 08:51:54AM -0400, Thomas David Rivers wrote:
GCC complains when I try to initialize the structure with something like:
struct validation_fun val_init[] = {
{init,valfun_init,0}
};
This can be avoided by:
struct validation_fun val_init[] = {
{(char *) (uintptr_t) init, valfun_init,0}
};
..but as a matter of fact, static, pre-initialized valfun structs are
the rule rather than the exception in this program, so having this
syntax for all of them seems.. well.. ugly :)
Ah.. I see..
(I don't think you need (uintptr_t) - you can cast a (const char *)
to a (char *) without having to go through that - I believe.)
E.. this was the whole point of this thread. I *can't* cast
a (const char *) to a (char *) when using the -Wcast-qual gcc flag -
the -Wcast-qual flag produces exactly this type of warnings, to make
sure you don't treat const * pointers as normal pointers, and pass them
to functions that do stupid things like modify them or free them :)
Is this C, or C++.. there are some differences in the type of
a constant character string between the two...
But - basically, what you are trying to describe is a field which
is sometimes 'const' and othertimes isn't... which doesn't make
sense in the context of the C standard... you'll need a cast
for the initialization, or some other approach besides static
initialization I believe... (or, just live with the warning...
which isn't pleasant at all.)
Well, I can't live with the warning with -Werror ;) So I guess I'll
live with casting in free() :)
G'luck,
Peter
--
If wishes were fishes, the antecedent of this conditional would be true.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: free() and const warnings
On Fri, Jun 08, 2001 at 03:02:56PM +0200, Assar Westerlund wrote:
Peter Pentchev [EMAIL PROTECTED] writes:
GCC complains when I try to initialize the structure with something like:
struct validation_fun val_init[] = {
{init,valfun_init,0}
};
This can be avoided by:
struct validation_fun val_init[] = {
{(char *) (uintptr_t) init, valfun_init,0}
};
..but as a matter of fact, static, pre-initialized valfun structs are
the rule rather than the exception in this program, so having this
syntax for all of them seems.. well.. ugly :)
What version of gcc is this? 2.96?
All versions of 2.95.x that I've tried seems to eat the following
program with:
gcc -O -g -Werror -Wcast-qual -c foo.c
/assar
struct validation_fun {
const char *name;
void*fun;
int dyn;
};
struct validation_fun val_init[] = {
{init,0,0}
};
My explanation was a reply to a suggestion to remove the 'const' in
the structure definition.
G'luck,
Peter
--
If I had finished this sentence,
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: free() and const warnings
On Fri, Jun 08, 2001 at 03:09:53PM +0200, Assar Westerlund wrote: Peter Pentchev [EMAIL PROTECTED] writes: My explanation was a reply to a suggestion to remove the 'const' in the structure definition. My fault. The code that I should have shown was without the 'const'. With gcc 2.95.3 and 'gcc -O -g -Werror -Wall -W -Wcast-qual -c foo.c' I don't get any errors with the const-less program (below). I was wondering if this is something that has changed in recent gcc. E d'oh, ok, my fault - it's not -Wcast-qual, it's -Wwrite-strings that causes the problem :) WARNS=2 in -current makes it go boom. G'luck, Peter -- If this sentence didn't exist, somebody would have invented it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Access to symbol table(including dynamics) at runtime
On Fri, Jun 08, 2001 at 12:09:39PM -0500, Kevin Day wrote: Is there a simple way that I can lookup a symbol name(by address) during runtime? I know I can exec nm, look up for the address I need, and get local symbols, but it would be really nice if I could get addresses of functions in dynamic libraries as well. I know I could use ldd to get offsets of each .so and calculate from there, but I'm starting to think I'm reproducing work that was done somewhere else. If someone could point me at a man page to something that can do what I need, tell me of a library that does something similar, or tell me why this can't be done, i'd be very thankful. :) OK, you asked for it, here's a minimalistic answer: dlopen(3) :) G'luck, Peter -- If wishes were fishes, the antecedent of this conditional would be true. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Wide character support - wchar.h?
On Fri, Jun 08, 2001 at 07:51:08PM +0200, Stefan Hoffmeister wrote: What are the status of / plans for support of select wide character routines, such as the ones declared in wchar.h? Particularly, I am looking for wcsoll, towupper, and towlower - IOW, the whole barrage of wide character transformation and collation :-) I haven't found anything conclusive in the mailing list archives. Has anyone tried to fake support for these functions via iconv operations from wide characters to the locale charset, performing a normal toupper / tolower / strcoll, and then transforming back? I am not certain whether these two transformations would be lossy or not. I guess I should leave the answers to someone more familiar with this than I am (next to none), but I do believe that Takuya SHIOZAKI [EMAIL PROTECTED] is currently working on multibyte support in -current's libc. G'luck, Peter -- Do you think anybody has ever had *precisely this thought* before? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sysKonnect dual gig adapter
On Fri, Jun 08, 2001 at 03:55:55PM -0400, [EMAIL PROTECTED] wrote: In a message dated 06/08/2001 1:28:22 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: 1) Can this be used as a 2 port gigabit NIC? 2) Does this NIC have hardware failover (that is, when power is cut the 2 ports will be physically tied together. I dont know of any PC plug in that does this, but its a neat feature. As the other respondent said, it's a 2-port NIC. If you want failover, you may want to check out Bill Paul's Fast EtherChannel module at: http://people.freebsd.org/~wpaul/FEC/ I specifically said physical failover. I guess no-one understands what that means? If it was a feature of the card, there would be no driver support required. But thanks for the info. I have no idea whether this card-feature-no-driver statement is correct in this particular case, but it is definitely not correct in general: if it is a feature of the card, and especially if it is an advanced feature of the card, you need driver support to enable it. 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-hackers in the body of the message
Re: make installworld hacking
On Wed, Jun 06, 2001 at 12:42:15PM -0700, Gordon Tetlow wrote: I have a problem, I installed a bunch of machines with a very stripped down set of distributions (bin, man, dict, krb5). I'd like to update the machines, but when I do an installworld, it's going to install a bunch more than that. Is there some way of only upgrading only the bin distribution (a la make distribute)? If not, would people be interested in me attempting such a feat? You can set a lot of NO_xxx variables in /etc/make.conf to disable building a *lot* of stuff. G'luck, Peter -- I am not the subject of this sentence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: rpc.statd
On Wed, Jun 06, 2001 at 09:39:39PM -0700, Dan Phoenix wrote: Jun 6 18:48:10 www rpc.statd: invalid hostname to sm_stat: ^XF7FFBF^XF7FFBF^ZF7FF BF^ZF7FFBF%8x%8x%8x%8x%8x%8x%8x%8x%8x%62716x%hn%51859x%hnM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM- [snip] this is a message in messages before a kernel paniced on freebsd 4.3. I have token liberty of disabling, what does this look like to you guys. As already pointed out, this should definitely not be the cause of a kernel panic. This is, exactly as the other poster explained, a Linux-targeting expoit which has absolutely no effect on FreeBSD's rpc.statd. G'luck, Peter -- If I had finished this sentence, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
free() and const warnings
Hi, Is free((void *) (size_t) ptr) the only way to free a const whatever *ptr with WARNS=2? (or more specifically, with -Wcast-qual) G'luck, Peter -- I've heard that this sentence is a rumor. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: free() and const warnings
On Thu, Jun 07, 2001 at 07:07:22PM +0300, Peter Pentchev wrote: Hi, Is free((void *) (size_t) ptr) the only way to free a const whatever *ptr with WARNS=2? (or more specifically, with -Wcast-qual) Uhm. OK. So size_t may not be enough to hold a pointer. What is it then - caddr_t? G'luck, Peter -- yields falsehood, when appended to its quotation. yields falsehood, when appended to its quotation. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Fixing documented bug in env(1)
On Sat, Jun 02, 2001 at 02:03:38AM -0400, Garance A Drosihn wrote:
At 9:12 PM -0700 6/1/01, Dima Dorfman wrote:
Honestly, I don't care about this all that much. I'll
let you and David debate this to your liking. If no
consensus develops in the next few days, I'll just
commit what I have now.
For whatever it's worth, it seems more reasonable to me
to use '--' instead of '=='. Since '--' has NO equals
sign in it, it clearly can't be the setting of an
environment variable.
It also strikes me that this might be another topic to
send thru [EMAIL PROTECTED], as Posix
might have something to say about what's appropriate.
..or at the very least to -arch.
FWIW, I, too, think that '--' would be a POLA-friendly choice.
However, if '==' were chosen, the patch to env.c would have to be
slightly modified, as attached.
G'luck,
Peter
--
This would easier understand fewer had omitted.
Index: env/env.c
===
RCS file: /home/ncvs/src/usr.bin/env/env.c,v
retrieving revision 1.5
diff -u -r1.5 env.c
--- env/env.c 1999/08/27 08:59:31 1.5
+++ env/env.c 2001/06/02 08:47:31
@@ -71,8 +71,13 @@
default:
usage();
}
- for (argv += optind; *argv (p = strchr(*argv, '=')); ++argv)
+ for (argv += optind; *argv (p = strchr(*argv, '=')); ++argv) {
+ if (!strcmp(*argv, ==)) {
+ argv++;
+ break;
+ }
(void)setenv(*argv, ++p, 1);
+ }
if (*argv) {
execvp(*argv, argv);
err(1, %s, *argv);
@@ -86,6 +91,6 @@
usage()
{
(void)fprintf(stderr,
- usage: env [-] [-i] [name=value ...] [command]\n);
+ usage: env [-] [-i] [name=value ...] [==] [command]\n);
exit(1);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: How to recompile kernel after minor changes?
On Fri, Jun 01, 2001 at 09:07:28PM -0400, Alfred Perlstein wrote: * Jiangyi Liu [EMAIL PROTECTED] [010601 20:25] wrote: Hi all, After just changing a little in sys/kern/kern_sig.c, how can I rebuild the kernel fast? I think it should not take such a long time as 'make buildkernel' does. Anyway, just kern_sig.c need to be recompiled and the kernel can be linked. So how do you guys do in such case? try: make buildkernel -DNOCLEAN And if you've really only changed kern_sig.c, add -DMODULES_WITH_WORLD, too. This will cut down the kernel compile time to the dependencies' and set generation (which cannot be avoided in any sane build), and then compiling only 4-5 files. G'luck, Peter -- If I had finished this sentence, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to recompile kernel after minor changes?
On Sat, Jun 02, 2001 at 04:31:45AM -0700, Kris Kennaway wrote: On Sat, Jun 02, 2001 at 11:58:23AM +0300, Peter Pentchev wrote: On Fri, Jun 01, 2001 at 09:07:28PM -0400, Alfred Perlstein wrote: * Jiangyi Liu [EMAIL PROTECTED] [010601 20:25] wrote: Hi all, After just changing a little in sys/kern/kern_sig.c, how can I rebuild the kernel fast? I think it should not take such a long time as 'make buildkernel' does. Anyway, just kern_sig.c need to be recompiled and the kernel can be linked. So how do you guys do in such case? try: make buildkernel -DNOCLEAN And if you've really only changed kern_sig.c, add -DMODULES_WITH_WORLD, too. This will cut down the kernel compile time to the dependencies' and set generation (which cannot be avoided in any sane build), and then compiling only 4-5 files. or -DNO_MODULES, as it's usually spelled when only doing a kernel compile :-) On -stable? [roam@ringworld:v4 /usr/src]$ fgrep NO_MODULES Makefile* [roam@ringworld:v4 /usr/src]$ fgrep NO_MODULES sys/Makefile* [roam@ringworld:v4 /usr/src]$ fgrep NO_MODULES sys/modules/Makefile* [roam@ringworld:v4 /usr/src]$ find /usr/share/mk -type f | xargs fgrep NO_MODUL ES [roam@ringworld:v4 /usr/src]$ Or is it somewhere else? G'luck, Peter -- This sentence every third, but it still comprehensible. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to recompile kernel after minor changes?
On Sat, Jun 02, 2001 at 02:35:32PM +0300, Peter Pentchev wrote:
On Sat, Jun 02, 2001 at 04:31:45AM -0700, Kris Kennaway wrote:
On Sat, Jun 02, 2001 at 11:58:23AM +0300, Peter Pentchev wrote:
On Fri, Jun 01, 2001 at 09:07:28PM -0400, Alfred Perlstein wrote:
* Jiangyi Liu [EMAIL PROTECTED] [010601 20:25] wrote:
Hi all,
After just changing a little in sys/kern/kern_sig.c, how can I rebuild
the kernel fast? I think it should not take such a long time as 'make
buildkernel' does. Anyway, just kern_sig.c need to be recompiled and
the kernel can be linked. So how do you guys do in such case?
try:
make buildkernel -DNOCLEAN
And if you've really only changed kern_sig.c, add -DMODULES_WITH_WORLD, too.
This will cut down the kernel compile time to the dependencies' and set
generation (which cannot be avoided in any sane build), and then compiling
only 4-5 files.
or -DNO_MODULES, as it's usually spelled when only doing a kernel compile :-)
On -stable?
[roam@ringworld:v4 /usr/src]$ fgrep NO_MODULES Makefile*
[roam@ringworld:v4 /usr/src]$ fgrep NO_MODULES sys/Makefile*
[roam@ringworld:v4 /usr/src]$ fgrep NO_MODULES sys/modules/Makefile*
[roam@ringworld:v4 /usr/src]$ find /usr/share/mk -type f | xargs fgrep NO_MODUL
ES
[roam@ringworld:v4 /usr/src]$
Or is it somewhere else?
*oof*
(extracts foot from mouth)
Of course, with a bit more looking, I found it in /sys/conf/Makefile.${arch}
G'luck,
Peter
--
If wishes were fishes, the antecedent of this conditional would be true.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Preliminary Tuning man page (was Re: Benchmarking FreeBSD (was ...))
On Wed, May 30, 2001 at 10:50:32AM -0400, Michael Adler wrote: Thank you for the tuning page! I and, I fear, others made the mistake of assuming that because SOFTUPDATES is in the kernel that it is automatically enabled for the disks. Nothing printed during boot leads me to believe otherwise and no mention was made of checking the flag using tunefs in /usr/src/UPDATING. My drives formatted with standard methods in the past had soft updates disabled. Perhaps there should be a message somewhere prominent encouraging people to check whether their drives really have soft updates enabled. It would also be useful if something during boot showed whether a mount would be using soft updates. You do realize, don't you, that just issuing a 'mount' command would show 'soft-updates' for the filesystems that have soft updates enabled? G'luck, Peter -- This sentence was in the past tense. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvsup problems
On Mon, May 28, 2001 at 01:48:10PM +0100, Koster, K.J. wrote: Dear All, Over the past few days I've been getting this error when I make update: ... Checkout ports/www/hypermail/files/patch-docs::Makefile.in Delete ports/www/jakarta-tomcat/files Updater failed: Cannot delete /usr/ports/www/jakarta-tomcat/files: Directory not empty *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. makalu# The error message is correct in the sense that that directory is not empty. It's got two patch fiels and a shell script in it. Permissions look fine (read-write for root). Manually deleting /usr/ports/www/jakarta-tomcat will allow me to run cvsup, but next time it will have recreated the files it tries to delete, triggering the error again next time I run cvsup. I've set SUP* in /etc/make.conf and the supfiles are stock 4.3-stable. I run cvsup with a make update from /usr/src. This problem occurs on both my build servers, which have nothing in common except the fact that they are PC's running FreeBSD-stable. What am I doing wrong? Kees Jan Look at http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27495 for a detailed analysis and a workaround by John D. Polstra, the author/maintainer of CVSup. Also, if you like compiling CVSup from source, update your net/cvsup (or net/cvsup-devel) port, and reinstall it. G'luck, Peter -- Do you think anybody has ever had *precisely this thought* before? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvsup problems
On Mon, May 28, 2001 at 05:04:18AM -0700, Kent Stewart wrote: What am I doing wrong? You need to remove the lines containing jakarta-tomcat in the checkouts.cvs* file /usr/sup/ports-all/ Some people have been able to just rm the port and others have had to also edit the checkouts file. You can read about it in http://www.freebsd.org/cgi/query-pr.cgi?pr=27495 Just rm'ing the port works for one CVSup run, removing the whole checkouts file does just the same as removing the jakarta-tomcat-related lines. There is, in fact, only one line that needs to be removed, but the PR has more information. G'luck, Peter -- If there were no counterfactuals, this sentence would not have been paradoxical. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc (cpp) include search path problem
On Thu, May 24, 2001 at 05:55:38AM -0400, Brent Verner wrote:
Hi,
I'm not sure if this has been the default for gcc/cpp on FBSD
for a while but I noticed it since some ports failed to build
due to includes (present in /usr/local/include) not being found.
Has this changed, or is that port (wget) just broken.
gcc does not have /usr/local/include in its include path by default.
Did you pick wget as a random example, or is it really broken for you?
If it is broken, you should probably update your ports collection,
and make sure that you do not have any CPPFLAGS defined in your
make environment: ports/ftp/wget/Makefile has included -I${PREFIX}/include
in its environment ever since rev. 1.17 from August 2, 1999:
http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/ftp/wget/Makefile
On second thoughts, you might have a problem if you are trying to
install the wget port in a location other than /usr/local.
If you change PREFIX, then the -I{PREFIX}/include directive would
point to the location you want to install wget at, not at /usr/local.
In that case, the proper course of action would be to first install
the devel/gettext port into the same location (using the same value
of PREFIX); then, its include files would be in ${PREFIX}/include,
its libraries would be in ${PREFIX}/lib, and wget would build just fine.
G'luck,
Peter
--
I had to translate this sentence into English because I could not read the original
Sanskrit.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Wed, May 23, 2001 at 08:17:12AM -0400, Andresen,Jason R. wrote: On Tue, 22 May 2001, Kris Kennaway wrote: On Tue, May 22, 2001 at 10:27:27PM +0300, Nadav Eiron wrote: I ran tests that I think are similar to what Jason ran on identically configured FreeBSD and Linux/ReiserFS machines. ResierFS is much much faster than UFS+softupdates on these tests. Linux (2.2.14-5 + ReiserFS): Time: 164 seconds total 97 seconds of transactions (103 per second) Files: 65052 created (396 per second) Creation alone: 6 files (1090 per second) Mixed with transactions: 5052 files (52 per second) 4936 read (50 per second) 5063 appended (52 per second) 65052 deleted (396 per second) Deletion alone: 60104 files (5008 per second) Mixed with transactions: 4948 files (51 per second) Data: 24.83 megabytes read (155.01 kilobytes per second) 336.87 megabytes written (2.05 megabytes per second) FreeBSD 4.3-RELEASE (ufs/softupdates): Did you enable write caching? You didn't mention, and it's off by default in 4.3, but I think enabled by default on Linux. I tried to leave the FreeBSD and Linux boxes as unchanged as possible for my tests (they are lab machines that have other uses, although I made sure they were idle during the test periods). I left write caching enabled in the Linux boxes, and left it disabled on the FreeBSD boxes. Personally, I'm hesitant to enable write caching on FreeBSD because we tend to use it on machines where we really really don't want to lose data. Write caching is ok on the Linux machines because we use them as pure testbeds that we can reconstruct easily if their disks go south. If the tests on the Linux machines are made to simulate how those Linux machines would operate if used as production servers, then do that: configure the Linux machines exactly as if they were your production servers. That is, if you want write caching off on production servers, turn it off at test time. G'luck, Peter -- If you think this sentence is confusing, then change one pig. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sysctl to disable reboot
On Tue, May 22, 2001 at 09:43:01AM +0800, David Xu wrote: Hello Jon, Tuesday, May 22, 2001, 12:30:44 AM, you wrote: JP I thought it would be useful to have a sysctl for disabling the JP keyboard reboot sequence. This functionality is currently JP available through the SC_DISABLE_REBOOT config option, but it's JP convenient to have this capability available at runtime, too. [snip] I have already failed many times to persuade them to add a sysctl about keyboard reboot, they prefer to change a keymap file and allow everyone to load it into kernel. You can always compile a keymap into the kernel, and disable loading any other keymaps. G'luck, Peter -- If I had finished this sentence, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: xargs(1) replstr patch
On Mon, May 14, 2001 at 11:31:53PM -0400, Garance A Drosihn wrote: At 4:09 AM +0200 5/15/01, Cyrille Lefevre wrote: Brian Somers [EMAIL PROTECTED] writes: I'd suggest going ahead and committing it ASAP - before people start ``discussing'' it again :oI from my point of view, it would be better to implement -i/-I than this hack which has no advantage in performance and functionality than : while read arg; do CMD LINE $arg ARGS; done test I think this proves the wisdom of Brian's suggestion... :-) ..with which, as I already stated, I completely agree :) - - - - Still, let me say that I do hope to get back to 'xargs', and add the -I option. I must admit my enthusiasm for doing -I wore off after seeing the current code to 'xargs'. Not only is -J more useful, but it is much less work to implement (given the current code as a starting point) than -I would be. Still, it *would* be nice to say we have '-I', just to match what the various standards list for options to 'xargs'. While I do like the idea of adding it, I'll admit that it isn't a particularly high priority on my list of things to do... Just as a side thought: one we have -J, I guess -I could be done as simply as emulating -n 1 and falling through to -J :) Then there would need to be another couple of checks, like -n and -I or -J and -I not being used simultaneously, but yes, I think it would really be *that* easy. Thanks to Garance and Dima for their work! -J is something that xargs really needed :) G'luck, Peter -- If you think this sentence is confusing, then change one pig. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: xargs(1) replstr patch
Seconded :) G'luck, Peter -- Do you think anybody has ever had *precisely this thought* before? On Sat, May 12, 2001 at 11:04:42AM +0100, Brian Somers wrote: I'd suggest going ahead and committing it ASAP - before people start ``discussing'' it again :oI Feel free to blame me for reviewing it !!! Folks, The attached patch adds a replacement string feature to xargs(1). There's a full description in the man page update (also attached), but the following should demonstrate the new functionality: dima@spike% ./xargs -J [] echo CMD LINE [] ARGS test CMD LINE this is the contents of the test file ARGS dima@spike% ./xargs -J [] echo CMD [] LINE ARGS test CMD this is the contents of the test file LINE ARGS dima@spike% ./xargs -J [] echo [] CMD LINE ARGS test this is the contents of the test file CMD LINE ARGS This is similar to, but not identical to, the -I option described in SUSv2. The latter allows the replstr ([] above) to be attached to other arguments, and appear multiple times. Furthermore, it implies '-n 1'. Although the features are similar, they can solve different problems; even if -I is implemented later, this (-J) would still be useful. -J also doesn't have the performance implications attached with -I. There was a nice, long thread about this on current a few weeks ago (topic: Re: cp -d dir patch for review (or 'xargs'?)). It was rather inconclusive, but nobody managed to come up with a way to *properly* and *easily* imitate this functionality. Writing a script to do this *properly* (i.e., handle environment growth) isn't as easy as it sounds (although it's possible, of course). The patch is a joint effort between myself and Garance Dorsihn (gad). Comments? Suggestions? Thanks in advance, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: adding a new function to libc
On Sat, May 12, 2001 at 05:05:44PM +0300, Valentin Nechayev wrote:
Hello Daniel Hemmerich!
[snip]
Here strnlen() is used which is non-standard but I saw it in ~4 quite
different projects (e.g. Linux kernel) with identical interface
and result value; a variant of implementation follows:
/* This is candidate to have optimized assembler variant */
size_t strnlen( const char* src, size_t max )
{
size_t n;
while( n max *src != '\0' )
n++;
return n;
}
I really hope you meant *src++ there :)
G'luck,
Peter
--
If there were no counterfactuals, this sentence would not have been paradoxical.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: kernel size..
On Thu, May 10, 2001 at 11:51:18AM +0100, vishwanath pargaonkar wrote: Hi, i have free bsd 4.2 stable. i did some changes may be 10-15 lines to kernel source. but thing i am amazed is kernel size. size of kernel.GENERIC is 3258128. but as of my kernel is 13068130 when i cheked it. my kernel is stable there is no probs. but y is size soo big?? Have you by any chance compiled it with debugging symbols? G'luck, Peter -- This sentence every third, but it still comprehensible. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
