Re: Project idea: Put PVM in /usr/bin/make
On Tue, Jan 22, 2002 at 07:20:06AM +0100, Poul-Henning Kamp wrote: I don't think it has been done with the berkeley make that we use, I have only found gnumake based ones. Checkout pmake sometime which is a relatively close derivative of FreeBSD's make(1). /usr/ports/devel/pmake -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
MMU-less FreeBSD
As a rough order of magnitude how hard would it be to port FreeBSD to an architecture (Motorola Coldfire) that doesn't have an MMU? I see some words on their site that the NetBSD folks might be working on some archs that require this. I got my hands on a board similar to the one in the NetTel eLia product and it runs on uClinux. I was just curious if porting FreeBSD would be a couple of month thing or much more involved. Thanks. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MMU-less FreeBSD
On Thu, Dec 13, 2001 at 06:19:42PM -0700, Warner Losh wrote: Hard. Lots of stuff relies on mmap, which basiclly requires an MMU or other tricks. The other tricks can be somewhat expensive... That's sort of what I figured. WRS and possible others use BSD as a basis for their embedded OS on archs without an MMU, right? Got any pointers to these tricks you talk about? Thanks. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MMU-less FreeBSD
On Thu, Dec 13, 2001 at 08:03:51PM -0800, Mike Smith wrote: If you want an OS, consider eCOS or one of the real embedded systems, don't make too much work for yourself trying to take a system that's entirely unsuited to the task and butchering it... In eCOS are you talking about this one? http://sources.redhat.com/ecos/ I'd prefer a free (as in beer) OS so most of the real embedded systems won't fit the bill unfortunately. I'd be glad to be proven wrong though if you have some URLs. :) -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MMU-less FreeBSD
On Thu, Dec 13, 2001 at 08:35:08PM -0800, Mike Smith wrote: Well, eCos is free-as-in-beer. From a quick glance at the license it looks to be a lot more like the GPL than a BSD license but I'll dig deeper. 'Any Modification which You create or to which You contribute must be made available in Source Code form under the terms of this License via an accepted Electronic Distribution Mechanism to anyone to whom you made an Executable...' You can try RTEMS as well; www.rtems.com. Ah yes, that's the one I was trying to remember. Thanks Mike. Funny thing (or maybe not) is that these folks are right here in town with me and for the life of my I couldn't remember their name. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
automating fsdb?
Is there an easy way to script interaction with fsdb? I'm trying to rebuild a disk that failed recently and I'm searching for the inode contains a directory that I need. However the entry in the root inode lists the inode for the directory I'm after as 0. I know it is there somewhere on the disk (or at least I hope it is) and I really don't want to have to type every number between 1 and 14,292,725 to find it. I thought if I could script fsdb I could do it much faster. In that vein I tossed together this silly little script but I'm missing something obvious because it doesn't work. Any suggestions besides don't do this? :) root@max(~)# cat foo.pl #!/usr/bin/perl -w open(FOO, | fsdb /dev/vinum/mirror) or die failed to start fsdb: $!; print FOO help\n; close(FOO); root@max(~)# ./foo.pl ** /dev/vinum/mirror Editing file system `/dev/vinum/mirror' Last Mounted on /a current inode: directory I=2 MODE=40755 SIZE=512 MTIME=Aug 11 20:41:59 2001 [0 nsec] CTIME=Aug 11 20:41:59 2001 [0 nsec] ATIME=Aug 21 03:01:03 2001 [0 nsec] OWNER=root GRP=wheel LINKCNT=8 FLAGS=0 BLKCNT=2 GEN=54e262d0 fsdb (inum: 2) * FILE SYSTEM STILL DIRTY * *** FILE SYSTEM MARKED DIRTY *** BE SURE TO RUN FSCK TO CLEAN UP ANY DAMAGE *** IF IT WAS MOUNTED, RE-MOUNT WITH -u -o reload To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
FW: gdb debugging tips
Not sure if this is hackers@ material but since it is FreeBSD- related and is probably something people on this can do in their sleep I'm forwarding this here after no response on chat. - Forwarded message from Steve Price [EMAIL PROTECTED] - I've been having problems with a software package for which I only have a binary with no debugging symbols. In talking to the folks that wrote the software I know what arguments the routine takes I just need to be able to see them in the debugger. Here's what I've done: Fire up the program. Attach to the pid of the running process with 'gdb lsv 10336'. I've set the breakpoint at the routine that I'm interested in 'break LH2P' and I've coerced the program to run to the breakpoint. Here's where I'm lost. I'm back in gdb and it is waiting for me to tell it what to do. I know the function LH2P takes one argument a 'char *'. How do I view a function's arguments? With debugging symbols this is as easy as 'where'. I figured 'info args' would be the ticket but all it says is 'No symbol table info avialable'. Now I'm betting the information from 'info frame' is the key but how to decipher it. Thanks. -steve - End forwarded message - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: synchronous IO
On Thu, Jan 11, 2001 at 09:44:49PM -0600, Dan Nelson wrote: # I don't think you really mean synchronous IO; All you need is some # buffering. If the toggling you're talking about is direct wave # generation (i.e. you have to do something for each byte in the sample), # your time restrictions are probably tight enough that you'll want # multiple buffers, filled by one process and drained by another one. # You mmap() some shared buffer space, fork your process into two, and # send buffer status messages over a pipe connecting the two. Process 1: # read a block of data from input file, fill an empty buffer, send the # buffer address over the pipe, repeat. Process 2: read a full buffer, # toggle buffer through the serial port, send the address of the buffer # back over the pipe for reuse. This ensures that the only operations P2 # does apart from waveform generation are a select, two reads, and a # write every sizeof(buffer). You could even toss the pipe and use # another bit of shared memory to keep track of buffer usage. # # If, on the other hand, the toggling merely tells the controller to play # a sample that you have already stored in the device's memory, then you # presumably have looser timing requirements and can get away with having # one process drain and fill the buffers as appropriate. This is similar # to how the kernel's soundcard drivers work; most soundcards read system # memory directly and signal the kernel via interrupts when its buffers # are getting empty. Thanks for the info. I don't think I was very clear in my first explanation. I have an RF transmitter that I control via a serial port on a FreeBSD box. I also have a sound card in that same computer connected to the transmitter. I'm sending commands to the transmitter in a sequence that looks like this. DIGITAL_BURST (commands sent via serial port) AUDIO (.wav files being played by the computer) TEXT_ECHO (text to display on the radio) I use DTR and RTS to control a set of relays in the transmitter to select which source of data to broadcast to the radios. I set the bits appropriately and I send the digital burst via the serial port. I need to make sure all of these bits have made it to the controller before I reset the bits to tell the transmitter to start sending the WAV file I'm playing on the computer. In the same respect I need to know when all of the sound data is completely sent so that I can put the controller back in serial IO mode and transmit the text to display on the radio. I don't have control over the message format nor can I change anything inside the transmitter. I only have control over the software that runs on the computer. This is why I believe I need something like synchronous IO. How would I otherwise know when all the data from one phase has been transmitted and I can go on to the next step? Currently the code is riddled with a bunch of nanosleeps that do their best to estimate how long it takes to transmit the data. This is kludgy at best and not very accurate because it depends on the load of the box and a bunch of other factors. I end up having to pad the times a bunch to try and cover all the possible things that could cause my rough-order transmission times to be missed. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: synchronous IO
On Fri, Jan 12, 2001 at 12:18:20PM -0800, Mike Smith wrote: # # You can ensure the serial output is drained with tcdrain(). There's is # probably an interface for checking the status of the sound buffer. Yes, this appears to have done the trick. # Looking in sys/soundcard.h, I would suggest calling SNDCTL_DSP_GETOSPACE # while the card is idle to determine the total amount of output space, # then poll while you're waiting for the sample play to end until it # returns to the "empty" level. I'll give this one a shot shortly. Thanks Mike. :) -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
synchronous IO
What are the secrets to doing synchronous IO with FreeBSD? I have this application that I'm writing where I need to play a WAV file but I need to make sure all the bits are sent on there way before I move on. The WAV file is being played through a controller that I have to toggle some bits via a serial port to get the WAV file through. Without doing a sleep(3) and praying that IO is complete is there another way? I'm pretty sure what I need is the equivalent of O_SYNC in SVR4, but I think I'm drain-bamaged (sic) because I haven't found the equivalent in BSD. Thanks in advance. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel boot question
On Tue, Nov 14, 2000 at 02:26:49PM -0800, John Baldwin wrote: # # WARNING: / was not properly dismounted # panic: kmem_malloc(536887296): kmem_map too small: 5685248 total allocated # # syncing disks... 8 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 # giving up on 3 buffers # Uptime: 2m4s # Automatic reboot in 15 seconds - press a key on the console to abort # Rebooting... # # Looks like your mountd is out of sync with your kernel. Yep, that was it. Thanks. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sigjmp_buf question
On Thu, 20 Apr 2000, Anatoly Vorobey wrote: # Look into src/lib/libc/i386/gen/_setjmp.S and other files in # the same directory for setjmp() and sigsetmp(). Basically, it'll store # edx, ebx, esp, ebp, esi, edi, and the CPU control word, in that order. Now I finally understand why trying to use the following construct to get the signalmask no longer works with version = 4.0. int signalmask = my_sigjmp_buf._sjb[6]; The status control word is there now and the signalmask comes after because its size can vary. In theory at least I should be able to get the signalmask now with something along the following lines. memcpy(signalmask, (my_sigjmp_buf._sjb[7]), sizeof(sigset_t)); Thanks. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
sigjmp_buf question
Where does one look in the source for the definition of what each of the ints in sigjmp_buf._sjb (or jmp_buf._jb for that matter) contain? The only occurrences of it (according to grep(1)) are in the header file machine/setjmp.h. I also looked into src/sys/i386/i386/machdep.c and didn't see anything that struck me as being what I'm looking for. TIA. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody know if there is any way to make ports use differentwork dir?
On Sat, 18 Dec 1999, Matthew Dillon wrote: # It would be nice if there were a way to tell the ports system to put the # work directory somewhere other then where it is currently placed. For # example, to put it in /usr/obj or something like that. Has anyone done # this? Try setting the value of WRKDIRPREFIX which is akin to MAKEOBJDIRPREFIX in bsd.obj.mk. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
docs for 3Com 3C515-TX NIC?
Anyone have detailed docs for 3Com's 3C515 NIC? I found Guy Helmer's driver, http://www.freebsd.org/~ghelmer/3c515/ but it didn't recognize the card I have. I was going to spend some time this weekend to see if I could figure out what was up. Just thought it might be easier if I had a little light reading material that described how the chip on it was supposed to work. :) Thanks. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: docs for 3Com 3C515-TX NIC?
On Fri, 30 Jul 1999, Guy Helmer wrote: # Have you tried booting with the "-v" flag to see the driver's probe # messages? Did you configure the card using the configuration "pnp" # commands before the kernel starts booting? For example, I did the former but not the latter. I'll stick it in a machine here at home (right after dinner) and give it a try. # config pnp 1 0 irq0 9 port0 0x360 enable os # # did the trick for me on a 3.2 system. When I did an install of FreeBSD # 3.2 on a machine with a 3C515, I was pleasantly surprised when sysinstall # captured this config command and wrote it to the kernel.conf file for # future boots. # # Anyway, the card is mostly the same as the Vortex (if_vx.c driver) but # with some ports changed. Sorry, I don't happen to have tech docs for the # card. Thanks for the hints. If I have to change anything to get it to work I'll send you some diffs. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
docs for 3Com 3C515-TX NIC?
Anyone have detailed docs for 3Com's 3C515 NIC? I found Guy Helmer's driver, http://www.freebsd.org/~ghelmer/3c515/ but it didn't recognize the card I have. I was going to spend some time this weekend to see if I could figure out what was up. Just thought it might be easier if I had a little light reading material that described how the chip on it was supposed to work. :) Thanks. -steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: docs for 3Com 3C515-TX NIC?
On Fri, 30 Jul 1999, Guy Helmer wrote: # Have you tried booting with the -v flag to see the driver's probe # messages? Did you configure the card using the configuration pnp # commands before the kernel starts booting? For example, I did the former but not the latter. I'll stick it in a machine here at home (right after dinner) and give it a try. # config pnp 1 0 irq0 9 port0 0x360 enable os # # did the trick for me on a 3.2 system. When I did an install of FreeBSD # 3.2 on a machine with a 3C515, I was pleasantly surprised when sysinstall # captured this config command and wrote it to the kernel.conf file for # future boots. # # Anyway, the card is mostly the same as the Vortex (if_vx.c driver) but # with some ports changed. Sorry, I don't happen to have tech docs for the # card. Thanks for the hints. If I have to change anything to get it to work I'll send you some diffs. -steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Per Lundberg wrote: # On Mon, 19 Jul 1999, Alex Zepeda wrote: # # It's quite easily argued that depending on a *NON STANDARD* getopt routine # is a bug. # # I know it isn't standard. But it works well, and is used by a lot of # programs. Perhaps it should have been put in another library than libc, # though. Actually, I'd better suggest this to the GNU people right ahead. How about gnugetopt? FreeBSD already has a port, devel/libgnugetopt, that does this. :) -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Per Lundberg wrote: # On Mon, 19 Jul 1999, Alex Zepeda wrote: # # It's quite easily argued that depending on a *NON STANDARD* getopt routine # is a bug. # # I know it isn't standard. But it works well, and is used by a lot of # programs. Perhaps it should have been put in another library than libc, # though. Actually, I'd better suggest this to the GNU people right ahead. How about gnugetopt? FreeBSD already has a port, devel/libgnugetopt, that does this. :) -steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
