mmap() w/ MAP_STACK question
Greetings, I'm interested in using mmap() with MAP_STACK. After writing a couple of test programs and looking at vm_map_insert() and vm_map_stack(), it appears that vm_map_stack() behaves as if MAP_FIXED were set. Why is this? I would like to allocate stack space without having to search for available blocks. Is there any harm in modifying vm_map_stack() to search for a free block, a la vm_map_insert()? I've not delved extensively into the kernel, and am asking before I tinker in new territory. :-) TIA, Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division E-Mail: [EMAIL PROTECTED] Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Where can I find out rules on blocking in threads?
Is this a library issue in libc_r?
I just wrote a quick test program using rfork(RFMEM|RFPROC) to
create a child thread.
I then had both the parent and the child attempt to open the pre-existing
file /tmp/blah with O_EXLOCK set. When I specify O_NONBLOCK, the child
open() fails immediately. When I do not specify O_NONBLOCK, the child
blocks indefinitely:
#if TRY_NONBLOCKING
# define O_ (O_NONBLOCK)
#else
# define O_ (0)
#endif
int main(int argc, char* *argv) {
thread_creation_using_rfork(RFPROC|RFTHREAD) ;
/* parent continues here */
printf("main: %d\n", open("/tmp/blah",
O_RDWR|O_EXLOCK|O_)) ;
for( ; ; ) ;
}
void childthreadproc(void *) {
/* child begins here */
/* fails for O_NONBLOCK, otherwise blocks indefinitely */
printf("child: %d\n", open("/tmp/blah",
O_RDWR|O_EXLOCK|O_)) ;
for( ; ; ) ;
}
Note that I've omitted the guts of rfork().
Therefore, it seems to me that the blocking is at the library level, not
the kernel level. Have I missed something?
Eddy
---
Brotsman Dreger, Inc.
EverQuick Internet / EternalCommerce Division
E-Mail: [EMAIL PROTECTED]
Phone: (316) 794-8922
---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Where can I find out rules on blocking in threads?
Date: Tue, 27 Feb 2001 15:15:33 + (GMT) From: E.B. Dreger [EMAIL PROTECTED] Is this a library issue in libc_r? I just wrote a quick test program using rfork(RFMEM|RFPROC) to create a child thread. Correction: RFTHREAD|RFPROC Sorry... I have RFMEM on the brain. The pseudocode gave the correct RFXXX flags. (I also typed "#if" instead of "#ifdef". FreeBSD multitasks better than I do this morning.) FWIW, does anyone know what Linuxthread's blocking behavior is? The original poster mentioned that Linux gave the desired behavior... what about the Linuxthreads library? Although I have written pthread applications, I prefer to do my thread programming at a lower level; hence my use of rfork(). Hopefully the info will be useful, though. Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division E-Mail: [EMAIL PROTECTED] Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Stupid debugging pthread question
Date: Thu, 1 Mar 2001 12:44:39 -0500 (EST) From: Peter Dufault [EMAIL PROTECTED] This is a stupid question, basically it's how to debug something. I have four cooperating p-threaded processes. One of them keeps getting a SIGSEGV with the address 0x752f422f. I'm not sure if that address is always the same, but with a given compile it is. The thing that's a pain is it is random. The four processes can run for a long time, or through several tests to completion, and then the nasty process gets that SIGSEGV. The thread that receives the SIGSEGV is random, the stack of the SEGV'd thread is trash, the rest of the threads in the offending process still have intact stacks. Arg! Sounds like maybe a buffer overrun or something might be trashing a return pointer. Not sure what the exact cause is, but if that address is not an actual address, I'd suspect that a return pointer is getting trashed. Any strings "/B/u" in your program? That would be stored as 0x752f422f. If you're using assembly with using %ebp for stack frame (yay!), then make certain %esp isn't getting corrupted. Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division E-Mail: [EMAIL PROTECTED] Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Stupid debugging pthread question
Date: Fri, 2 Mar 2001 08:04:52 -0500 (EST)
From: Peter Dufault [EMAIL PROTECTED]
Any strings "/B/u" in your program? That would be stored as 0x752f422f.
If you're using assembly with using %ebp for stack frame (yay!), then make
certain %esp isn't getting corrupted.
(I meant _without_ %ebp, but I didn't want to repost.)
Very good, I read those high bits off-by-one and stupidly didn't recognize
the ascii:
(gdb) x/s $esp-8
0x826b400 dtablecount+6528:"/wd0/B/usr-src/lib/libc_r/uthread/uthread_dup2.c"
(gdb)
I guess it is the "thread_fd_lock_debug/_thread_fd_unlock_debug"
calls with __FILE__ that push this on the stack. I'll build a
debuggable libc_r and see I see.
H. That "/B/u" portion is toward the beginning of the string, not the
end as one would expect from an overrun.
It looks like the string is getting written to -4(%esp,1), where %esp is
the initial stack pointer. Note that the return address is at 0(%esp,1).
What is the first variable that you declare in the function?
/* Note use of "trashme" instead of "trashme" */
void foo (void) {
char *trashme;
strcpy((char*)trashme, "/wd0/B/usr-src/libc/libc_r...");
}
If you compile using -fomit-frame-pointer, I _think_ that "trashme" would
be at -4(%esp,1). (Otherwise, %ebp would be saved at that address.)
It looks like you might be passing the address of a 32-bit variable to a
string function when you should be passing the contents. Anyone have any
other ideas off the top of their head?
Eddy
---
Brotsman Dreger, Inc.
EverQuick Internet / EternalCommerce Division
E-Mail: [EMAIL PROTECTED]
Phone: (316) 794-8922
---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
need help: mmap() / vm_map_stack()
Greetings,
This is something of a repost of an earlier question, but in a different
vein. I should mention that I'm using 4.2-R.
Has anyone modified vm_map_stack(), in /usr/src/sys/vm/vm_map.c, to search
for the first suitable open block?
I tried modifying vm_map_stack() based on vm_map_find(), but get:
* kernel panic upon boot ("Bad entry start/end for new stack entry")
* kernel panic when attempting to search for a block using mmap(MAP_STACK)
* _duplicate_ values returned when searching using mmap(MAP_STACK)
depending upon the exact code that I tried. I know that the first two
symptoms are when I made a fubar vm_map_stack(). I'm rather new to the
kernel code, so I'm sure that I'm doing something wrong...
For the last problem, I made certain that I had vm_map_lock()'ed, ran at
splvm()... same thing. I then sleep()'ed between mmap() calls... same
thing.
I've concluded that I need to learn more about vm_map_entry_t and friends,
but wanted to see if anyone had any suggestions before I went chasing the
wrong thing...
I'm almost tempted to try having vm_map_stack() call vm_map_find() with
size SGROWSIZ, shrink it to the initial size, then alter vm_map_entry_t
entries as needed based upon current vm_map_stack() code.
Advice? Just keep digging? :-)
Eddy
---
Brotsman Dreger, Inc.
EverQuick Internet / EternalCommerce Division
E-Mail: [EMAIL PROTECTED]
Phone: (316) 794-8922
---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: pthread_exit proto
Date: Sun, 04 Mar 2001 12:15:36 -0800 From: Farooq Mela [EMAIL PROTECTED] It's not actually gcc-specific code, its more of a hint to the compiler to not warn about something like, main() "falling off the end" when there is actually an exit(0); at the end of it. If GCC knows exit() never returns to its caller it doesnt warn. Much like Borland's "#pragma" directives for the WinDos world. Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division E-Mail: [EMAIL PROTECTED] Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Machines are getting too damn fast
Date: Sun, 04 Mar 2001 19:39:09 -0600 From: David A. Gobeille [EMAIL PROTECTED] It would also be interesting to see the numbers for an Athlon/PIII system with DDR, if anyone has such a machine. Personally, I'd be [more] interested in a ServerWorks III HE core chipset with four-way interleaved SDRAM. :-) If one _truly_ needs the bandwidth of Rambus (which, IIRC, is higher real-world latency than SDRAM), then how about having the bus bandwidth to back it up? Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division E-Mail: [EMAIL PROTECTED] Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp status?
Date: Thu, 8 Mar 2001 14:36:22 -0500 (EST) From: [EMAIL PROTECTED] Actually, the FA310TX comes in a couple of different forms. One with the Tulip chipset and another with PNIC, I believe. It seems that they changed chipsets partway into the life of the product code for the card. IIRC, Rev. A is Tulip, B is ???, C is PNIC, D is Netgear's own. My memory is fuzzy on this, and I have no NG cards handy, but I think that the progression has been something like that. Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division E-Mail: [EMAIL PROTECTED] Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
The ideal NIC (Re: if_fxp - the real point)
Bear with me and allow me my delusions while I daydream... What with FPGA technology as reasonable as it is, and the amount of hw/sw talent on these lists, maybe people should band together and come up with a NIC? Maybe have native mode + Tulip/PNIC clone compatibility mode. Take a look at www.opencores.org for a start. What production volumes are required before ASICs are feasible? What about having a FreeBSD CDROM + NIC bundle featuring whatever card gets designed? If ya can't join 'em, beat 'em. Okay. Back to work and reality. :-) Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division E-Mail: [EMAIL PROTECTED] Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A novel idea....
Date: Thu, 5 Apr 2001 01:40:38 -0700 From: [EMAIL PROTECTED] 20) Multi-staged booting. You don't need to change your MBR when you install a new kernel (or want to roll back to a different kernel). I think I've only been stuck high and dry w/o a bootable system twice in four years and well over 400+ servers. With Linux, you're SOL if you screw up LILO. With FreeBSD, leaving the MBR alone gives a much safer boot procedure. Not only that, but with the console on a serial port _before_ running the kernel... Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
aic7xxx angry (MPARERR) in 4.2-R
Greetings, (If I'm OT, please feel free to tell me where to go... as in which list, not that other place. ;-) I have a couple of AHC cards. When I cold boot, I receive MPARERR before "Waiting XXX seconds for SCSI bus to settle". Panic. I've tried two different AHC boards and two different motherboards, and *always* receive MPARERR on cold boot. *Never* after a warm boot. Quick STFWing via Google told me that I'm not the first: http://www.luga.at/mailing-lists/aic7xxx/msg09868.html It appears that 4.0-C was the topic of discussion, and the problem was fixed circa 2000/02/09... but my 2940 and 2940UW are most unhappy on 4.2-R. Now what? Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
TCP intercept?
Greetings all, I'm no kernel hacker, and trying to think of useful little projects to change that. ;-) AFAIK, FreeBSD lacks support for TCP intercept. Is anyone already working on this? Would it be of interest to anyone? My initial thoughts are that it should be implemented in the same neighborhood as stateful firewall code, as the two are rather closely related. Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
brainstorm: intermediate disk caching
Greetings all, I just had a brainstorm... I was thinking about database servers with several spindles in a RAID 5 array. Write performance is inherently disappointing -- which may or may not be an issue. Would it be worth the trouble to design an intermediate cache, whereby data are quickly written to a spool disk, then to the final destination? Sort of like softwares that cache CDROMs on HDD... My gut feel is that this would be more trouble than it's worth, would not net any overall performance*reliability (expressed as a product) gain, and that one might actually realize a p*r decrease. Comments, flames, larts, and funny stares appreciated. Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: (316) 794-8922 --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: brainstorm: intermediate disk caching
Date: Mon, 28 May 2001 19:49:40 +0200 From: Christoph Sold [EMAIL PROTECTED] My gut feel is that this would be more trouble than it's worth, would not net any overall performance*reliability (expressed as a product) gain, and that one might actually realize a p*r decrease. IMHO it would speed up your DB significantly to have it a) run on a RAID 10 array and b) have it run on the raw disk. Two layers of lag reduced (well, for reads it is possibly only one layer). RAID 1+0 is what I use... but I was thinking of scalibility. In a five- drive array (using one as a hot spare), RAID 1+0 has 67% the capacity of RAID 5. More expensive per megabyte, but handles more db ops. However, the numbers become less favorable with bigger RAID 1+0 arrays. Also, intermediate caching *does not* inherently defeat the purpose of RAID. IO could be cached to a RAID 1 volume, then transferred to the RAID 5 volume... my question was if it was worth the hassle. Of course, with 36 GB drives readily available, maybe I shouldn't worry until I have a database larger than 72 GB. ;-) Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: (316) 794-8922 --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: brainstorm: intermediate disk caching
Date: Mon, 28 May 2001 17:54:24 +0100 From: Dominic Marks [EMAIL PROTECTED] [ snip ] disc caching. The idea of perhaps caching writes onto a RAID-0 system I meant caching onto an arbitrary volume, probably using a simple journalling filesystem. Personally, a RAID 1 volume would be my choice, but the type of target volume would have no bearing on the implementation. RAID 1 writes are slower than RAM (duh!) but faster than RAID 5... and they don't have the reliability issues associated with writeback RAM cache (duh!). and then transferring them is possible. But it sounds to that such a system would be hard to setup. Such is what I thought... but I still had to ask. :-) Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: (316) 794-8922 --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: brainstorm: intermediate disk caching
Date: Mon, 28 May 2001 19:01:37 -0500 (CDT) From: David Scheidt [EMAIL PROTECTED] [ snip ] If you're really interested in database performance, remember Spindles is good. Spreading your IO load over as many seperate disks, on as many independent IO channels as practical will improve performance. There's the problem. With RAID 1+0, total the storage of the spindles, and half of that is usable. With RAID 5, it asymptotically approaches unity. Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: (316) 794-8922 --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
Date: Sat, 16 Jun 2001 11:56:45 -0700 (PDT) From: Matt Dillon [EMAIL PROTECTED] This is old. The guys running the tests blew it in so many ways that you might as well have just rolled some dice. There's a slashdot article on it too, and quite a few of the reader comments on these bozos are correct. I especially like comment #41. Don't worry, FreeBSD stacks up just fine in real environments. If the programmers who wrote that software used poll() on FreeBSD 4.2, then I'd say that they need to RTFM and learn about kernel queues and accept filters. Not to mention that anyone using a kernel out of the box needs to be larted. Personally, I think that article casts more doubt on the authors than on FreeBSD... Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
Date: Sat, 16 Jun 2001 16:57:04 -0400 (EDT) From: Albert D. Cahalan [EMAIL PROTECTED] You mean they should just optimize for FreeBSD, or should they also use completion ports on Win2K, /dev/poll on Solaris, and RT signals on Linux? What is wrong with using the portable API on every OS? If you want an all-out performance test, use what's available. is fine to use fancy FreeBSD features. Otherwise no, it isn't OK. FreeBSD shouldn't need nonportable hacks to keep up with Win2K and Linux. Like mounting the volume async? :-P What size swap partition did they use? How hard is it to compile a custom kernel? What optimizations did they use on the respective compilers? You're sounding like a Microsoftie, demanding that code be written (Troll alert) to the latest OS-specific API to get decent performance. The decent performance issue has been addressed. For all-out performance, accept filters and kqueues are not that new. Not to mention that anyone using a kernel out of the box needs to be larted. If you run Google or Yahoo, sure. If the admin is really the guy hired to make web pages selling potted plants, no way. And I suppose that routers must also coddle the admin using FP, because it's too hard to filter bogons or configure netmasks by hand? BGP should be plug and play, eh? A certain amount of manual work is too much -- don't get me wrong. But there's a point where, if you want to be a network admin, you simply must know WTF you are doing. If an admin is too dumb to at least start tuning a system, will they know enough to asymmetrically encrypt sensitive info before storing it in a database? If not, I'm less than excited about buying from them. Anybody who needs a wizard, singing mouse, or dancing teddy bear to bind an IP address to a NIC scares me. Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Sat, 16 Jun 2001, Albert D. Cahalan wrote: I'd say the real winner was NT. It mostly kept up with Linux, trashed FreeBSD and Solaris, and didn't need any tuning to do it. FWIW, somebody pointed out (and I overlooked) that the test ran RSETs instead of real mail messages. Excuse me, but when in the hell was the last time that your MX sat around receiving RSETs all day?! Anybody running NT or 2000 out-of-the-box with IIS... yup, that's a real winner. http://www.eeye.com/ Next benchmark: How long does it take for an untuned box to get 0wn3d? OEM NT4, anybody? Remember, it must be straight out of the box. Back to work for me. I have to build / upgrade a few servers; when done, there will be no more Linux on our network. I guess the only choice now is if I should tune these systems to work well in real life, or if I want to have a system that RSETs mail quickly... Anybody have a real-world benchmark suite for our new Web server? I'm thinking of something along the lines that sends the request, only uses HEAD instead of GET or POST... Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
question: aio / nbio / kqueue
Quick question, hopefully not too basic for this list: AIO vs. non-blocking IO vs. kernel queues I'm familiar with (and *love*) kernel queues. Non-blocking IO is straightforward. AIO seems simple enough. My question is, from a performance standpoint, in what situations are these techniques most appropriate? TIA, Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
libc_r locking... why?
Please pardon the cross-posting; I'd rather keep responses on whichever list is more appropriate. Why are bind(2), accept(2), kevent(2), etc. wrapped in libc_r? I thought that the spl() calls prevented kernel recursion in the current SMP system, and that a mutex handled reentrance in SMPng. [Please correct me if/where I am mistaken.] I can understand things like malloc(3), lseek(2), read(2), and write(2) being serialized, but I'm confused about [some of the other] syscall wrappers. Can somebody please elaborate, or direct me to a reference? Big TIA, Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
Date: Thu, 28 Jun 2001 21:28:56 -0500 From: Chris Costello [EMAIL PROTECTED] Please pardon the cross-posting; I'd rather keep responses on whichever list is more appropriate. Currently, the pthreads implementation is done entirely in userland. This means that a syscall which would normally block needs to have code in it to check if it would block (write(2) is a really simple example of this), and if it would, schedule another thread (cancelling, or blocking, the calling thread) to run, and eventually get back to the thread which is blocking on write, check for/read more data, cancel again, etc., until the requested amount of data has been read or an error occurs. So it's a thunk/kludge not only to enforce proper behavior, but also to prevent the process from blocking and stalling other threads? This makes sense. This example, of course, applies to instances where write() is called on a file descriptor which does _NOT_ have O_NONBLOCK set. kevent(2), bind(2), accept(2) etc. all do the same thing for the same reasons. The reason that I asked is because I'm writing a program that uses rfork() in the same manner as the new rfork_thread(). I couldn't understand the need to wrap kevent(2), bind(2), or accept(2)... In my mind, I was thinking data integrity, trying to prevent processes in the same thread family from stepping on one another. Blocking is not a problem; where I can't use non-blocking calls, I use a worker thread. I guess that I was looking at man pages and bits of libc_r code without understanding the pthread implementation. I knew that it was userland, but I thought that it created multiple processes... if this is not the case, then I was apparently comparing apples to mangoes. Am I correct that libc_r does _not_ use multiple processes to create threads? Grepping for fork in *.c files under /usr/src/lib/libc_r leads me to believe that this is so... ...I think that, with your prompting, I've answered my question. Thanks, Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
(on -hackers only, as this post is beyond the -smp charter) Am I correct that libc_r does _not_ use multiple processes to create threads? Grepping for fork in *.c files under /usr/src/lib/libc_r leads me to believe that this is so... That's correct. It's implemented using setjmp/longjmp, and storing stack pointers and the like in thread-specific data structures. Ah, okay. Thanks. I use this approach, too, but not for threads; I relegate this type of architecture to state machines. I guess that cramming multiple threads into a single PID would be considered a state machine of sorts... Sounds like I need to just ignore libc_r and stick to syscalls and what I've been doing. I must note, however, that the uthreads source directory for libc_r provides a handy checklist of functions that might need a bit of TLC. :-) Thanks again, Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
(Warning: rather long message) Date: Fri, 29 Jun 2001 00:50:30 -0700 From: Terry Lambert [EMAIL PROTECTED] [ ... wrapped fd using functions in libc_r ... ] [ fd locking, to prevent chopping feet from beneath ] As-needed serialization to prevent breakage = proper behavior. I should have been more clear. 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. After my recent question regarding AIO, it looks like it's time to bite the bullet and use that as well. [ ... thinking that pthreads used multiple processes ... ] This is not the case. So I've learned. I'm glad that I didn't use pthreads, then. :-) The user space threads library does what the original idea of threads was intended to do, before people started treating it as the only hammer they had to pound on the SMP problem with in order to achieve SMP scalability: it utilizes the full quantum of the process, and minimizes context switch overhead. Kernel threads don't do either of these things well, in almost all existing implementations out there. Agreed on all counts. I'm tempted to continue eschewing the pthread library. I've unrolled code, and store state info in a purpose-specific FSM control block. Maybe I reinvented the wheel, but it wasn't that difficult. Am I correct that libc_r does _not_ use multiple processes to create threads? Yes. All threads run in a single process. The threads are not intended as a workaround for the SMP scalability problem. A good thing, IMHO. I was starting to look at libc_r to check my work; I _prefer_ launching multiple processess for SMP scalability, and having an untainted threading model. Note that you are not going to be able to combine your rfork approach with this, if your resulting processes end up running on different CPUs: this is because the Running processes on multiple CPUs is one goal. [ libc_r locks don't assert lock, not MP-safe ] So the lock prefix is the only way to enforce cache coherency? Do you have handy a good reference on IPIs, other than the kernel APIC code (and, of course, Google and NorthernLight searches)? Good to know, but, I'm not using libc_r... I was looking at existing code to help me double-check mine as I go. I'm synchronizing processes with a giant lock token that each process cooperatively passes to the next... to simplify: who_has_lock++ ; who_has_lock %= process_count ; Each processes' critical path first checks to see if it holds the token; if so, it performs the tasks that require it, such as locking a finer-grained lock or mutex. It then passes the token, and continues through its critical path. If a thread has nothing to do, I nanosleep(2) to prevent the critical path from degenerating to an extended spin. I'm considering using socketpair(2)s, with a process blocking indefinitely on read(2) until another process write(2)s to awaken it... If you need kernel threads, look at the Linux kernel threads in the ports collection (it's a kernel module that builds and installs as a package). You probably don't, since performance of kernel threads is really only Correct me if I'm wrong, but the only place in my model that really might benefit from kthreads would be the scheduling? i.e., rather than screwing around with nanosleep(2) or socket calls, I could cut the cruft and interact more directly with the scheduler via kthread mechanisms? about a 20% increment, if you implement them the SVR4 or Solaris (pre-2.7) or Linux way. It's probably better to implement with FreeBSD threads as they currently exist, and get massive SMP scalability when KSE's are brought into the source tree. KSEs... where can I read up? Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
Date: Fri, 29 Jun 2001 18:33:52 +0300 From: Peter Pentchev [EMAIL PROTECTED] 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 Yes. it's the process that blocks, and none of the other threads ^ can run until the end of the syscall. Again, I am *not* using pthreads. Worker thread = totally separate process, created via rfork(2). One process blocks, others continue running. To reiterate: I'm *not* using pthreads or libc_r. I wanted to check my work, and began looking at libc_r code, under the faulty ass-umption that it ran multiple processes. Now that I know that threads are implemented in a single process, and that blocking calls are thunked to non-blocking calls, the locking that I originally questioned makes sense. Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
CPU affinity hinting
(Cross-posting again... I'm willing to be larted with a herring if this is unacceptable for the content presented.) I was thinking about CPU affinity on SMP systems the following is on-list brainstorming. Take a two-way box running 10 httpd and 10 smtpd processes. Assuming equal CPU time requirements, it would make sense to bind httpd to one CPU, and smtpd to the other. Simple, but not realistic. Maybe smtpd requires more CPU time. Fine... limit one processor to smtpd, run leftover smtpd on the other CPU, and run httpd _only_ on the processor handling leftover smtpd. Or consider ten instances of a single program that uses four processes, sort of like squid * 10: It would make more sense to have similar processes grouped on the same CPU. After watching processes switch CPUs via top, I got to thinking... could there be, and would it be useful to have, a mechanism where processes could tell the kernel my magic number is 6819732, and the kernel would try to keep all processes with said magic number on the same CPU? Is this solution worse than the problem (cache thrash and switching CPUs)? I suppose that the kernel could do a quick, numerically-simple hash of the ELF metadata, as opposed to program-specified magic. This would handle the httpd/smtpd case, with less fear of magic number collisions, but not rfork(2)ed threads. Or, instead of hashing ELF metadata, the kernel could compute a hash based on all IP ports bind(2)ed by the program within the first few seconds of operation. (Obviously unsuitable for short-lived programs, but those could probably be handled via least-busy CPU assignment.) Perhaps a hybrid approach: cpu_hint = hash(elf_metadata, hint) % num_cpus ; where hint is specified by the process in a group? Thoughts? Criticisms? Flames? Beatings with a stinky fish? Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
Date: Fri, 29 Jun 2001 20:33:51 +0200 From: Bernd Walter [EMAIL PROTECTED] I can't see how you make shure that on SMP systems all CPUs have the same meaning from memory content. Normaly you would use a mutex or similar before accessing a data range from another thread which also enshures that the CPU specific caches and buffers are syncronised. If you don't do this it may happen that you write a variable and another thread uses this variable using another CPU before the first CPU has writen this memory seeable for others and works with an outdated content. Passing a token between threads. When a thread has the token, it may assert a lock or a mutex on an object. Again, I subscribe to threads being lightweight; cooperative sharing is better than preemptive or trying to grab a lock before another thread does. Any good references on MP standard? Is the lock prefix the only way to force cache coherency? Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
(Personal CCs trimmed; back to Bernd and cross-posting -smp and -hackers) Date: Fri, 29 Jun 2001 21:18:18 +0200 From: Bernd Walter [EMAIL PROTECTED] Passing a token between threads. When a thread has the token, it may assert a lock or a mutex on an object. Again, I subscribe to threads being lightweight; cooperative sharing is better than preemptive or trying to grab a lock before another thread does. A Token may not be enough because writes may be reordered. Usually a mutex is a lock with some kind of memory barrier. But it _is_ locked. The thread_with_token++ ; thread_with_token %= num_threads ; was oversimplified. It's more like xorl %ecx,%ecx movl thread_with_token,%eax incl %eax cmpl %eax,num_threads movzl %ecx,%eax lock movl %eax,thread_with_token to pass the token, where thread_with_token is in shared memory. Each process does the above. When a process has the token, it's safe to claim mutexes and such without worry of another thread (without token) accessing simultaneously. Mutex/lock ops also have lock asserted. If this is inadequate, then I need to do some head-scratching. If you can fetch the lock on a CPU you know that the CPU previous owning the lock has flushed everything up to the point of coherence of what was written until the lock was released. Here is where I want to learn more about cache coherency, inter-processor interrupts, and APIC programming. I'd imagine that the latter two are lower-level than I'd be using, but I still want to know the how and why beneath the scenes. Memory barriers and the read-modify-write operations (or locked operations like on ALPHA) are accessible from user code - but I don't know of any platform independend functions. Nor do I. Any good references on MP standard? Is the lock prefix the only way to force cache coherency? A good explanation for this kind of thing was in Programming with POSIX Threads in Chapter 3.4 Memory visible between threads. I'll have to check it out. I [believe that I] understand about the inherent races in SMP, but more reading is always better... However, I'm still interested in x86-specific coherency mechanisms. Any info? I know you are not usung pthreads but the memory problems are the same. Correct. I just wanted to make certain that we were on the same page, no pun intended. Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: CPU affinity hinting
Date: Fri, 29 Jun 2001 13:14:58 -0700 From: Matthew Rogers [EMAIL PROTECTED] Why not just use First in line, Next processor available ? Then you wouldn't care what processor did which task. That was my question: Would the added complexity of CPU affinity hinting be worth the reduction in cache misses and switching processes, by preventing long-running processes from constantly switching CPUs? FILNPA is fine for short-lived processes, but longer-running ones switch CPUs, perhaps unnecessarily. Hmm, maybe even have each processor a dedicated memory space, and programmable functionality. Oops, that's a Field Programmable Gate Array, and there going to make Legacy computing look stupid. FPGAs, . Transputers, . Neuromatrix, . In my mind, you have a need for multiprocessing Non-specific and Specific tasking. In some ways we are multiprocessing anyway on some level. Videocard 3d processing, sound card. You mean that Winmodems and main memory-based video aren't the keys to high performance? You mean that Intel is being silly when they justify faster chips by saying now you can eliminate three $20 DSPs by buying our latest architecture? :-) So why do we need a GOD chip, ie the chipset controlling access to processors and busses ? That's because that's the way it was done before the 286. Time to leave the bus. :) Arguably so from a hardware standpoint. But, in the mean time, I was trying to think of ways to help SMP performance. :-) Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: CPU affinity hinting
Date: Fri, 29 Jun 2001 21:44:43 -0500 From: Michael C . Wu [EMAIL PROTECTED] The issue is a lot more complicated than what you think. How so? I know that idleproc and the new ipending / threaded INTs enter the picture... and, after seeing the HLT benchmark page, it would appear that simply doing nothing is sometimes better than doing something, although I'm still scratching my head over that... This actually is a big issue in our future SMP implementation. I presumed as much; the examples I gave were trivial. I also assume that memory allocation is a major issue... to not waste time with inter-CPU locking, I'd assume that memory would be split into pools, a la Hoard. Maybe start with approx. NPROC count equally-sized pools, which are roughly earmarked per hypothetical process. For example: If MAXUSERS=80 -- NPROC=1300, a machine with 256 MB might use 192 kB initial granularity for mmap() requests, giving 128 MB to each processor as a first approximation. Now, no locking is needed on mmap() until a given CPU's pool hits low water, and steals from another pool. This would hopefully be infrequent, particularly assuming that memory allocations would be distributed roughly equally between CPUs. I'm assuming that memory allocations are 1:1 mappable wrt processes. Yes, I know that's faulty and oversimplified, particularly for things like buffers and filesystem cache. There are two types of processor affinity: user-configurable and system automated. We have no implementation of the former, Again, why not hash(sys_auto, user_config) % NCPU? Identical processes would be on same CPU unless perturbed by user_config. Collisions from identical user_config values in unrelated processes would be less likely because of the sys_auto pertubation. Granted: It Is Always More Complicated. (TM) But for a first pass... and alfred-vm has a semblance of the latter. Please wait patiently. Or, if impatient, would one continue to brainstorm, not expect a response (i.e., not get disappointed when something basic is posted), and track -current after the destabilization? :-) Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Quick question: AIO / SMP / process-based threading
Quick question(s): 1. Is AIO SMP-safe? 2. If not, how could one force coherency? (Read and rewrite locked a word from each cache line?) Is it worth the effort, or should one not use AIO across process boundaries? I'm asking primarily about 4.x, unless anyone has good guesses of how 5.x will be. ;-) I'll also keep an eye out for KSEs... thanks to Terry and others for alerting me to those. (KSEs really answer most of my recent questions, but I don't think that I can wait that long, nor do I have the kernel background to really offer any assistance in the KSE project...) TIA, Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Quick question: AIO / SMP / process-based threading
Date: Sat, 30 Jun 2001 22:28:29 -0500 From: Alfred Perlstein [EMAIL PROTECTED] Can you point to some specific PRs about this or crashdumps before (or at least while) taking pot shots at the AIO implementation? In the mean time, until somebody can substantiate that claim... is AIO SMP safe? I see that aiocb.aio_buf is declared as volatile, so I would presume so. I just want to be sure that, if an aio call runs on one CPU, another CPU can access *aio_buf and be 100% certain that the data are coherent. aio_buf = mmap() using MAP_HASSEMAPHORE -- good idea, bad idea, pointless? TIA, Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
Date: Sun, 1 Jul 2001 16:07:38 +0200 From: Bernd Walter [EMAIL PROTECTED] In -currents NOTEs I found this: # CPU_DISABLE_5X86_LSSER disables load store serialize (i.e. enables # reorder). This option should not be used if you use memory mapped # I/O device(s). A good sign that it may be at least possible on some CPUs. OK that's not an MP capable CPU. This is an encouraging starting point... at least the issue is similar. It's also in 4.3-R, so I can grep kernel source. What you need is an x86 guru or asume worst which will be the best thing anyway - otherwise you can't use it on other machines and sometimes programms get very old. I thought that one had to assert lock to guarantee cache coherency... an ugly hack would be to movl(%pagebase,%index,1),%eax lock movl %eax,(%pagebase,%index,1) for every cache line in a page. Ugly and slow... I'd much rather find out if there's a way to tell the chipset flush all pending writes in this block, and ensure that both CPUs have the same view. I also don't know what the following is: # CPU_WT_ALLOC enables write allocation on Cyrix 6x86/6x86MX and AMD # K5/K6/K6-2 cpus. H. Being concerned about x86 SMP, I've overlooked anything non-Intel. Might be worth checking out what's there... I've oft learned what I wanted via an indirect route. Did you try to read MP chipsets white papers? No. I guess that I can give that a shot. I can't say very much about coherency problems on x86 but I can say for shure that you have to worry about this on every other MP platform including IA64. Even if it's a non-issue on x86, I'd rather use macros to insert proper code on ia64, axp (if I ever port to that), and go to nothing on x86 (if that is indeed the correct behavior). Looks like I need to do some digging on bus snooping, cache coherency, read/write reordering, MTRRs, and APICs. :-) Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD 4.0-release installation problems
(Responding on-list so there's no flood of private responses. Considered cross-posting to move the thread, but hoping it will just die on -hackers.) This topic would probably be better suited to freebsd-questions. Date: Mon, 2 Jul 2001 09:00:15 -0700 (PDT) From: Zac M. Speidel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: FreeBSD 4.0-release installation problems FYI: 1. Not sure why you're running 4.0-R 2. Processor speed means nothing. A PC BIOS is a PC BIOS is a PC BIOS, and they all have the same limitations. 3. Consider a small (8 MB is more than enough) partition to hold /boot. Note that I'm using partition in the WinDOS/Linux sense; a slice would be the correct BSD term. Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
Date: Tue, 03 Jul 2001 03:17:12 -0700 From: Terry Lambert [EMAIL PROTECTED] who_has_lock++ ; who_has_lock %= process_count ; Your unsimplified assembly is not happy, and neither is this. You want to use a LOCK CMPXCHG to implement your mutexes; the LOCK prefix makes it a barrier instruction, which is needed to ensure that two processors don't operate on their L1 cache contents, and then both attempt to write back, where one wins the race, but both think they own the lock. So I see now. Brainstorming, something like: ;; eax = my id to match with token movl$my_id,%eax ;; ecx = next process = (my_id + 1) % process_count xorl%edx,%edx leal1(%eax,1),%ecx lock cmpl $process_count,%ecx movzl %edx,%ecx ;; edx = my id, for use after cmpxchg ;; if ( who_has_lock == my_id ) who_has_lock = ecx movl%eax,%edx lock cmpxchg%ecx,$who_has_lock ;; see what happened cmpl%edx,%eax jnz *we_didnt_have_the_token I'll look at the kernel code, compare with the above, and run with it. Thanks for beating on my head with a bigger hammer until things clicked. :-) I've bookmarked a page of dangerous instructions that require the lock prefix. If a thread has nothing to do, I nanosleep(2) to prevent the critical path from degenerating to an extended spin. I'm considering using socketpair(2)s, with a process blocking indefinitely on read(2) until another process write(2)s to awaken it... This would work, but it will destroy your SMP scaling that you want to achieve, since you will effectively serialize your processes running. Typo on my part. If a _process_ has nothing to do, I put the thing to sleep. I presume that it's [at least sometimes] better to have a sleeping process than to have to launch a new process. Eddy --- Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SCSI Boot order
Date: Thu, 5 Jul 2001 14:42:41 +0100 From: Leubner, Achim [EMAIL PROTECTED] One of our testers has a boot problem with FreeBSD 4.3. He installed the OS on a onboard SCSI drive. After installing the FreeBSD driver of our ICP controllers and inserting a ICP card with one disk attached, the system has a boot problem. FreeBSD cannot mount the root file system (I think because the ICP controller becomes the first controller and the onboard controller is now the second controller). Is there any way to change the boot order? Which kernel module is responsible for the order of driver loading? Any help is greatly appreciated. Many thanks! Boot order is a BIOS thing. Turn off the ICP BIOS, keep the on-board SCSI BIOS on. You might need to manually wire down which SCSI bus and drives are what devices in your kernel config. i.e., what might have been called /dev/da0 could now be /dev/da1. Personally, I'd change /etc/fstab instead of messing with device naming in the kernel. Eddy --- Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Authentic FreeBSD (Re: FreeBSD Mall now BSDCentral)
Date: Sat, 7 Jul 2001 15:51:51 -0700 (PDT) From: Richard Hodges [EMAIL PROTECTED] Sure, no argument there. Taking Wes' suggestion, maybe there is an opportunity in the official distribution distinction. How about a certificate of authenticity which costs the vendors $1 or $2 (or I donated daemon blood. ;-) whatever), and shows the customer that their choice of vendors helped FreeBSD financially. Incidentally, this certificate might also be a selling point for those twisted individuals that just don't understand free software :-) Heck, if you're headed that route, why not have different levels of FreeBSD partners, based on what the CD vendor is willing to give back? Eddy --- Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Authentic FreeBSD (Re: FreeBSD Mall now BSDCentral)
Date: Sat, 07 Jul 2001 20:27:16 -0700 From: Jordan Hubbard [EMAIL PROTECTED] such. It's often the case that actually tracking the effectiveness of, say, $500 towards some theoretically worthy cause costs you thousands of dollars in man-hours. Heck, If somebody tried to donate a million bucks to the foundation right now, I'd actually expect the current directors to probably scream and run away. :-) How about... 1. Programming contests with prizes (results committed) 2. Buying publicity (surely newscasters can be bribed) 3. Distributing as many CDs as AOL (might need more than $1M) ;-) Okay, I'll be good now. Eddy --- Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Mall now BSDCentral
Date: Sun, 8 Jul 2001 12:29:40 EDT From: [EMAIL PROTECTED] If theres one thing that non-unix people have learned about unix is that the cost of the product is insignificant compared to the value of time in getting it to function. Its already free to anyone who knows what they are doing. A distribution has to add value by cutting the time to usefulness. Precisely why I dislike(d) RedHat. Hairy SysV-style init scripts, tons of setuid root binaries, every daemon under the sun running by default... ick! Yet this is the most popular distro among newbies, simply because they can get the illusion of results without any Clue. *ix also increases awareness of what one _should_ know. Look how easy it is to crack an out-of-the-box NT4/5 install. Just because one can get results doesn't mean that it's the right way. If somebody needs wizards, singing mice, and dancing teddy bears to bind an IP to a NIC, are they really competent enough to run a network? Sorry, not knowing what the @#$! one is doing does not translate into the OS having a high time until usefulness. IMHO, FreeBSD's TUU and TCO are _so_ much lower than Linux or NT... that's one of the non-technical reasons that I love it so. On a totally different subject, I'm curious: [EMAIL PROTECTED] seems like such an ironic e-mail address that I must enquire about the story behind that one... Eddy --- Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Mall now BSDCentral
Date: Mon, 09 Jul 2001 12:09:08 -0700 From: Terry Lambert [EMAIL PROTECTED] The most obvious way to do this, IMO, is to make FreeBSD more accessiblle for use in commercial ventures, be it embedded systems or as a backdrop for commercial software using it as a platform on which some company puts their own face forward. To this end, I'd say: * More emphasis on Pico * Pick'n'choose which specifc files (not just sets) This means making it substantially easier to do things like building distributions with custom kernels, greatly simplified default installation type things, etc.. I'm not opposed to a GUI-based easy install and config, so long as I don't have to use it or even have it on disk. I rather like sysinstall, and would _not_ want something GUI or anything like RH's installer or YaST. Eddy --- Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Network performance tuning.
Date: Thu, 12 Jul 2001 21:09:44 -0400 From: Leo Bicknell [EMAIL PROTECTED] http://www.iet.unipi.it/~luigi/sack.html H. I don't yet know enough about kernel architecture to know in advance how I'd fare trying to patch that into 4.x (I expect the line number to be off, obviously), but I have a box at home: * 4.x (currently 4.3-R) * Running squid * Win 98 clients pulling Web pages through the proxy * Used for telnet and ssh if testing would be of service. Eddy --- Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Network performance tuning.
Date: Fri, 13 Jul 2001 13:29:03 -0400 From: Leo Bicknell [EMAIL PROTECTED] (The window autotuning was an interesting read...) I think you're doing good work, but I'm concerned you're going down a road that's going to take a very long time to get right. It is not necessary to calculate the bandwidth*delay in order to prevent over-buffering. Preventing overbuffering only requires tracking the maximum bandwidth*delay value, assuming that we always want the ability to buffer that much data. I think the number of cases where it decreases significantly over the peak for a long enough time to make a difference is minimal. This sort of reminds me of semi-empirical vs. ab initio molecular modeling in Chemistry. MOPAC is great for quick calculations with fairly loose tolerances; a good semi-empirical calculation is better than a crude ab initio. However, for super-high precision, lengthy ab initio calculations in Gaussian are the rule. Being a realtime application, I'd presume that empirical methods are better for this sort of work. Jitter would also screw up the bw*del values. Fully knowing the value over time could lead to optimizations like shrinking the buffers, or attempting to prevent some packet loss by not over-increasing the window. However oscellation and other issues I think are going to make this very complex. I'd imagine that dynamic buffer sizing (high water / low water) would make more sense. For new connections, we could pull from a cache of memoized, empirically-determined window sizes keyed by subnet* or IP, a la ARP- or route-caching. * The implementation would be ugly and imprecise, but a userspace daemon to give hints based on BGP or OSPF tables might be interesting. Probably impractical, but I'm just brainstorming. I'd imagine that it would make more sense to find a subnet that includes two IPs with similar window sizes, and aggregate them automatically. Perhaps do this on the insert. As for preventing oscillation, one can use moving averages and still stick with integer math if needed for x86 performance. Eddy --- Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
outbound SOCK_STREAM - force source addr?
Greetings all, Any way to force the source address for an outbound SOCK_STREAM? I know that one can do it for SOCK_DGRAM... but I've found no way to do so for, say, a TCP connection. Example: + dc0 has 192.168.0.1/24 as primary IP, 192.168.0.2/24 as alias + an outbound connection wishes to come from 192.168.0.2. I know that one can always use an IP socket (duh!), but it's silly to reinvent the TCP stack to force the source addr. I've not looked at jail(2) to see if there's anything similar. I don't necessarily want to _use_ jail(2), but if there's code that one could hack into a setsockopt(2) call, that would be a start. Finally, I don't care about how loose or tight allowed-address restrictions are, as long as any local address is acceptable. (Local address = one for which the machine answers ARP requests.) Suggestions? Have I overlooked something simple? TIA, Eddy --- Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: AIO issues... or not?
Date: Fri, 5 Oct 2001 13:58:22 -0500 From: Alfred Perlstein [EMAIL PROTECTED] [ snip ] Where was the warning (so it can be removed)? /usr/src/sys/i386/conf/LINT Not sure about Alpha. Eddy --- Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
dynamic linking: want to play with fire
Greetings, I'm currently STFWing, but would appreciate any pointers that anyone might have. I wish to manually perform dynamic linking. I'd like to load an executable, .so, or .o, and _manually_ handle the symbol fixups. I looked at dlfcn.c, but found next to nothing there. Next stop: kernel source? I'm reading up on the ELF file format... Any hints? Eddy Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence -- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
dlopen(), ld.so, and library wrappers
Greetings all, I wish to accomplish the following: 1. Program foo loads shared object bar using dlopen() and dlsym() 2. bar needs certain symbols resolved, which foo intercepts. For example, foo might wrap malloc() or open() to provide its own behavior... much like subclassing window procedures on that OS from Redmond, only I'm wrapping library calls instead of window callback procedures. Any suggestions, or should I get busy hacking ld-elf.so? And, yes, I know that one must be very careful when playing with fire. If anyone wishes to tell of monsters or horror stories, I'd appreciate those as well. -- MTIA! Eddy P.S. -- Please CC me. I'm not currently subscribed. Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dlopen(), ld.so, and library wrappers
Date: Tue, 2 Apr 2002 11:05:52 -0800 From: Alfred Perlstein [EMAIL PROTECTED] From the dlopen manpage: I reread that right before initial post. If dlsym() is called with the special handle RTLD_NEXT, then the search for the symbol is limited to the shared objects which were loaded after the one issuing the call to dlsym(). Thus, if the function is called Am I confused on loading order? I thought that linked libraries were loaded _before_ dlopen() shared objects. from the main program, all the shared libraries are searched. If it is called from a shared library, all subsequent shared libraries are searched. RTLD_NEXT is useful for implementing wrappers around library functions. For example, a wrapper function getpid() could access the ``real'' getpid() with dlsym(RTLD_NEXT, getpid). How does that sound? So you're saying that: 1) Program foo contains function called getpid() 2) Program foo links with libc 3) foo.getpid uses dlsym(RTLD_NEXT, getpid) to call libc.getpid 4) Shared object bar, loaded by foo, will receive a pointer to foo.getpid instead of libc.getpid when getpid is resolved. ??? If that'll work, great. But I didn't interpret the manpage that way. I read it as shared object bar being able to provide a wrapper for program foo, which is the _opposite_ of what I want. I'll try the above. If that doesn't do what I want, I'll see if I can restate more clearly. -- Eddy Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dlopen(), ld.so, and library wrappers
Date: Tue, 2 Apr 2002 11:05:52 -0800 From: Alfred Perlstein [EMAIL PROTECTED] From the dlopen manpage: [ snip ] Works great, less coding. Looks like I just misunderstood the manpage and/or the workings of the dynamic linker. Time for me to have some fun. And, no, I'm not using wrappers for security... that would be silly. -- Thanks! Eddy Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: per-user or -proc CPU reservation and limits
TL Date: Thu, 09 May 2002 10:34:33 -0700 TL From: Terry Lambert TL Rice University has been doing that a lot with their TL licenses, these days. I don't know if they would have done TL this anyway, or if it's an overreaction on their part to TL FreeBSD ignoring their patches. Eclipse/BSD is a product of Bell Labs... Rice just had a useful reference. TL Since they aren't a publically funded university, I don't TL think there is much you can do, unless the work was done TL under a DARPA grant, and even then, it would be a pain to TL fight. Noted in case that is ever applicable... TL Back to the original topic, though... you might want to ask TL Alfred for his CPU affinity patches that he did. They are ...but this sounds more logical, anyway: Rather than hassling with encumbered software, why not extend the work of all the goodies going in to 5.0? H. I think I need to get 5.0-DP1 installed on a box. Hey, Alfred, if you're following the thread... I'm interested in playing with the patches! (And if you're not following, I'll just bug you off-list. *grin*) TL more for locking things to a CPU than affinity, but they can TL do what you want to do (even though I think what you seem to TL want looks more like an SVR4 fixed scheduling class). A quick Google search leads me to believe that you're correct. Maybe I also need to get my UltraSPARC up and running with Slowaris and play around a bit. -- Eddy Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
any file -- symbol in .o file
Greetings all, While writing CGIs in C, I'm getting a bit sick of escaping quotes and line continuations in strings. Not a huge deal, perhaps, but there must be a better way. Strings end up in .data or .rodata in object files to be linked... I'm about to whip up a utility that will take any arbitrary file and store the contents in a .o file (complete with symbol names so one can actually link, of course). Instead of compiling: const char foo[] = \Escape\ chars make strings in 'C' code...\n\ ...messy. Line breaks can be troublesome and add\ unexpected whitespace to one's code. ; simply put the desired unescaped text in a file: Escape chars make strings in 'C' code... ...messy. Line breaks can be troublesome and add unexpected whitespace to one's code. then run the utility. Large amounts of embedded HTML/XML/XHTML are just beginning to bug me. Note that it wouldn't be limited to text, either. If one wished to take a raw-binary lookup table for a sine wave, that would make no difference. If there's interest, I'll post it for download. I also have a few other ideas, and certainly am open to suggestions. -- Eddy Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: any file -- symbol in .o file
JM Date: Sun, 19 May 2002 21:41:05 -0700 JM From: Jonathan Mini JM Take a look at file2c. You'll need to run the source through JM the compiler first, but that is easy to do with make. H. Definitely produces the desired results for the simple case that I mentioned. In fact, more complex things (hash functions, tries, etc.) can be accomplished by writing a quick bin to perform the proper transform, then feeding that to file2c; a shell script can orchestrate everything. I guess I'll run with that for now. Off the top of my head, the only feature file2c can't provide is user-specified data alignment. (Unless, of course, someone corrects me and alerts me to a C preprocessor directive similar to assembly's .align.) Thanks! -- Eddy Brotsman Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
