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: The design of the MD5 crypt() in FreeBSD
On Sat, Jun 02, 2001 at 07:46:28AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Spike Gronim writes: I understand the literal meaning of /usr/src/lib/libcrypt/crypt-md5.c, and the algorithm it uses to create it's output. However, I do not understand the design criteria or functional purpose of several elements of the process. At the time the MD5 hash was written we could not use anything DES based due to ITAR. The design criteria was to get a strong, preferably stronger than DES, password encryption, which would make brute force attacks very much harder. [snip] The overall MD5 chewing code were done to try to make the algorithm unsuitable for hardware implementation (MD5 is already pretty bad for that) the various unlinear steps would make it practically impossible to do a hardware implementation of anything but the basic MD5: you would still need to iterate through it. Ah, I hadn't considered that. That pretty much answers my question. I don't know enough about cryptographic math to argue that this algorithm is perfect or even good. I know it to be better than the DES things, and infinitely better than the scrambler we had to fill the hole for DES at the time. In light of this theoretical backing, I introduced the $1$ marker, which allows the algorithm to be replaced in a backwards compatible way (as already done by OpenBSD). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -- --Spike Gronim [EMAIL PROTECTED] Oh yes? An obscene triangle which, has more courage than the word. 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, 2 Jun 2001, Peter Pentchev wrote: 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. Yes, using '--' seems like a reasonable thing to do. Consistency with other uses of an 'argument that separates parts of the command line', etc. is one reason that I can easily come up with. -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: UFS large directory performance
In message [EMAIL PROTECTED], Matt Dillon writes: What are your commit plans? It looks extremely well contained, it could be committed to -current and then -stable a few days later without any destabilizing impact at all for when the option isn't specified. ... The only potential problem I see here is that you could end up seriously fragmenting the malloc pool you are using to allocate the slot arrays. And, of course, the two issues you brought up in regards to regularing memory use. Thanks for the comments :-) Yes, malloc pool fragmentation is a problem. I think that it can be addressed to some extent by using a 2-level system (an array of pointers to fixed-size arrays) instead of a single large array, but I'm open to any better suggestions. If the second-level array size was fixed at around 4k, that would keep the variable-length first-level array small enough not to cause too many fragmentation issues. The per-DIRBLKSIZ free space summary array is probably relatively okay as it is now. The other main issue, that of discarding old hashes when the memory limit is reached, may be quite tricky to resolve. Any approach based on doing this from ufsdirhash_build() is likely to become a locking nightmare. My original idea was to have ufsdirhash_build() walk a list of other inodes with hashes attached and free them if possible, but that would involve locking the other inode, so things could get messy. Ian 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 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 :-) Kris PGP signature
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: How to stop console messages to rlogin sessions?
On Sat, Jun 02, 2001 at 12:34:31PM +0300, Giorgos Keramidas wrote: On Fri, 1 Jun 2001, Brian Reichert wrote: On Fri, Jun 01, 2001 at 04:59:34PM -0500, Bob Willcox wrote: I have just upgraded my debug/test systems here to 4.3-stable and I'm now getting all of my device driver printf's spewed to my root rlogin windows. When these two systems were 4.0 and 4.2 these messages weren't printed here (I am capturing them on the serial port). How do I revert this so that when I rlogin as root to these boxes the kernel printf's don't get written to my rlogin session? Is this a syslog issue? If so, dick with syslog.conf as neccessary... As a matter of fact it is. If you copy /usr/src/etc/syslog.conf over your /etc/syslog.conf you get these lines added there: *.err root *.notice;news.err root *.alert root Just edit /etc/syslog.conf and remove them. Restart syslogd (issuing a 'killall -HUP syslogd' as root will do it) and you're set to go :) I have done this and the messages have stopped. :-) Thanks to all that replied! Bob -giorgos -- Bob Willcox Egotist, n.: [EMAIL PROTECTED] A person of low taste, more interested in himself than me. Austin, TX-- Ambrose Bierce, The Devil's Dictionary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: UFS large directory performance
: :Thanks for the comments :-) Yes, malloc pool fragmentation is a :problem. I think that it can be addressed to some extent by using :a 2-level system (an array of pointers to fixed-size arrays) instead :of a single large array, but I'm open to any better suggestions. I do precisely this for the swap meta-support structures associated with VM objects. It works very well and it means you can use the zone allocator for the fixed size structures. :If the second-level array size was fixed at around 4k, that would :keep the variable-length first-level array small enough not to :cause too many fragmentation issues. The per-DIRBLKSIZ free space :summary array is probably relatively okay as it is now. 4K = (IA32) 1024 directory entries / 2 (approximate hash slop) = 512 directory entries? That seems quite reasonable but I would use a smaller block size.. 512 bytes (remember, with zalloc there is no overhead for allocating smaller structures. Read on! I would further recommend a (dynamic) array of pointers at the first level as part of the summary structure. Any given array entry would either point to the second level array (the 512 byte allocations), be NULL (no second level array was necessary), or be (void *)-1 which would indicate that the second level array was reclaimed for other uses. During a lookup your hash algorithm would operate as per normal but when it skips to the next top level array index it would test for NULL (search ends, entry not found) and (void *)-1. (void *)-1 would indicate 'search ends but the result is indeterminant, you have to rescan the directory'. By using a smaller block size for the second level array you create more slots in the first level array which gives the system a better chance of reusing a second level array block for other purpopses without seriously compromising performance for file creates, deletions, and lookups on the directory. e.g. lower chance of the lookup hitting the (void *)-1 reclaim mark in the first level array. :The other main issue, that of discarding old hashes when the memory :limit is reached, may be quite tricky to resolve. Any approach :based on doing this from ufsdirhash_build() is likely to become a :locking nightmare. My original idea was to have ufsdirhash_build() :walk a list of other inodes with hashes attached and free them if :possible, but that would involve locking the other inode, so things :could get messy. : :Ian If the zone allocator is used for the second level block allocations it shouldn't be a problem. You can (had better be able to!) put a mutex around zone frees in -current. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: UFS large directory performance
Oh yah, one more thing. At risk of making the second level block
more complex you might want to make a real structure out of it rather
then a simple array. Something like this:
struct whateverYouNameTheSecondLevelBLock {
short use;
charfiller[sizeof(void *) - sizeof(short)];
secondLevel_t array[128];
};
We could maintain a use count on the second level block which
would allow us to make better decisions on which one to reuse.
You could get more complex and keep the second level blocks on
their own LRU queue, making reclaims trivial. This would require
a doubly linked list node (lruq) and a backptr to allow you to
unlink the second level block from the first level array, e.g.
'*secondLevelBlock-backptr = (void *)-1;'
struct whateverYouNameTheSecondLevelBLock {
TAILQ_ENTRY(blah) lruq;
firstLevel_t *backptr;
short use;
charfiller[sizeof(void *) - sizeof(short)];
secondLevel_t array[128];
};
For now I would recommend the first approach (you could add a queue node
to the summary structure to allow scanning all the summary structures).
This second approach would be a good second-round approach.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
ptrace
I am coding a simple debugger, and I need to know the proper way to
save and restore the state of the debugger's terminal when the child
process is not executing. For example, if the debugger ptraces a process
which gets a signal and returns control to the debugger, the debugger
needs to restore the original terminal settings, in case the ptraced
process messed with them. I am currently using a setup like this:
if (isatty(STDIN_FILENO))
tcgetattr(STDIN_FILENO, termin);
if (isatty(STDOUT_FILENO))
tcgetattr(STDOUT_FILENO, termout);
if (isatty(STDERR_FILENO))
tcgetattr(STDERR_FILENO, termerr);
PtraceProcessUntilSignal();
if (isatty(...)) {
tcsetattr(STDIN_FILENO, TCSANOW, termin);
tcsetattr(STDOUT_FILENO, TCSANOW, termout);
tcsetattr(STDERR_FILENO, TCSANOW, termerr);
}
For simplicity I did not show the error checking above, but the terminal
calls never return -1.. The above code does not work - if I hit CONTROL-C
or give the ptraced process another signal, it returns control to the
debugger, but the debugger's terminal does not get restored properly.
ie: the debugger will still accept input but does not output stuff
correctly. The terminal sometimes doesn't scroll up properly when you type
newlines etc..
If anyone has any info which could help me out here I would greatly
appreciate it as I am not very familiar with the tcgetattr/tcsetattr
stuff. Thanks in advance.
Patrick Alken
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Patch to fix code that kills procs when swap runs out (stable)
I'll probably commit something similar to this to -current on sunday,
and -stable next weekend. This patch should fix the process killing
part of the VM system. It fixes two things:
(1) It starts killing processes a little earlier, before the machine
truely hoses itself. This should avoid the deadlocks.
(2) It locates the largest process by counting the approximate amount
of swap used as well as the RSS. Before it was just counting the
RSS which resulted in it choosing the wrong process (often choosing
small processes instead of large processes).
Alfred, I'm cc'ing you. If you have some time, could you check the
vmspace_swap_count() routine? What do I need to mutex it for -current?
For -stable I don't think there's an issue since VM objects are not
instantiated/destroyed by interrupts.
All suggestions are welcome.
--
On another note, I am MFCing the O_DIRECT patches I did a weekend or two
ago to -stable now.
-Matt
Index: vm/vm_map.c
===
RCS file: /home/ncvs/src/sys/vm/vm_map.c,v
retrieving revision 1.187.2.8
diff -u -r1.187.2.8 vm_map.c
--- vm/vm_map.c 2001/03/14 07:05:05 1.187.2.8
+++ vm/vm_map.c 2001/06/03 04:22:03
@@ -220,6 +220,41 @@
}
/*
+ * vmspace_swap_count() - count the approximate swap useage in pages for a
+ * vmspace.
+ *
+ * Swap useage is determined by taking the proportional swap used by
+ * VM objects backing the VM map. To make up for fractional losses,
+ * if the VM object has any swap use at all the associated map entries
+ * count for at least 1 swap page.
+ */
+int
+vmspace_swap_count(struct vmspace *vmspace)
+{
+vm_map_t map = vmspace-vm_map;
+vm_map_entry_t cur;
+int count = 0;
+
+for (cur = map-header.next; cur != map-header; cur = cur-next) {
+ vm_object_t object;
+
+ if ((cur-eflags MAP_ENTRY_IS_SUB_MAP) == 0
+ (object = cur-object.vm_object) != NULL
+ object-type == OBJT_SWAP
+ ) {
+ int n = (cur-end - cur-start) / PAGE_SIZE;
+
+ if (object-un_pager.swp.swp_bcount) {
+ count += object-un_pager.swp.swp_bcount * SWAP_META_PAGES * n /
+ object-size + 1;
+ }
+ }
+}
+return(count);
+}
+
+
+/*
* vm_map_create:
*
* Creates and returns a new empty VM map with
Index: vm/vm_map.h
===
RCS file: /home/ncvs/src/sys/vm/vm_map.h,v
retrieving revision 1.54.2.1
diff -u -r1.54.2.1 vm_map.h
--- vm/vm_map.h 2001/03/14 07:05:06 1.54.2.1
+++ vm/vm_map.h 2001/06/03 03:58:51
@@ -375,6 +375,7 @@
void vm_freeze_copyopts __P((vm_object_t, vm_pindex_t, vm_pindex_t));
int vm_map_stack __P((vm_map_t, vm_offset_t, vm_size_t, vm_prot_t, vm_prot_t, int));
int vm_map_growstack __P((struct proc *p, vm_offset_t addr));
+int vmspace_swap_count __P((struct vmspace *vmspace));
#endif
#endif /* _VM_MAP_ */
Index: vm/vm_pageout.c
===
RCS file: /home/ncvs/src/sys/vm/vm_pageout.c,v
retrieving revision 1.151.2.7
diff -u -r1.151.2.7 vm_pageout.c
--- vm/vm_pageout.c 2000/12/30 01:51:12 1.151.2.7
+++ vm/vm_pageout.c 2001/06/03 04:12:27
@@ -1094,10 +1094,14 @@
}
/*
-* make sure that we have swap space -- if we are low on memory and
-* swap -- then kill the biggest process.
+* If we are out of swap and were not able to reach our paging
+* target, kill the largest process.
*/
+ if ((vm_swap_size 64 vm_page_count_min()) ||
+ (swap_pager_full vm_paging_target() 0)) {
+#if 0
if ((vm_swap_size 64 || swap_pager_full) vm_page_count_min()) {
+#endif
bigproc = NULL;
bigsize = 0;
for (p = allproc.lh_first; p != 0; p = p-p_list.le_next) {
@@ -1119,7 +1123,8 @@
/*
* get the process size
*/
- size = vmspace_resident_count(p-p_vmspace);
+ size = vmspace_resident_count(p-p_vmspace) +
+ vmspace_swap_count(p-p_vmspace);
/*
* if the this process is bigger than the biggest one
* remember it.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
